Debug My House

Owned by Kim Stimpson
Last updated: 03 Nov, 2016 by Simon Chapman

My House returns no data

This is due to a non-printable character held in a data source (e.g. a PostgreSQL table) that can not be processed by MapServer. iShare sends a request to MapServer that contains all the necessary layers and if MapServer fails because of a character in one layer it the entire response fails. The result is 'No results found' for all layers.

In the iShareMaps.all.log file (D:\Astun\iShare\n.n\WebApps\WebService\logs) the call to MapServer that fails will look something like this:

http://localhost/mapserver/mapserv?map=D:/iShareData/client_name/_MapServerConfig/base.map&mode=nquery
&mapxy=591453.25+188605.54499817
&layers=Green_Belt+Conservation_Areas+Floodzone+Planning_Applications
&map.layer[Green_Belt]=TOLERANCE+5+TEMPLATE+'_MapServerTemplates\AllMaps_Green_Belt_fields.xml'+TOLERANCEUNITS+METERS
&map.layer[Conservation_Areas]=TOLERANCE+5+TEMPLATE+'_MapServerTemplates\AllMaps_Conservation_Areas_fields.xml'+TOLERANCEUNITS+METERS
&map.layer[Floodzone]=TOLERANCE+5+TEMPLATE+'_MapServerTemplates\AllMaps_Floodzone_fields.xml'+TOLERANCEUNITS+METERS
&map.layer[Planning_Applications]=TOLERANCE+5+TEMPLATE+'_MapServerTemplates\AllMaps_Planning_Applications_fields.xml'+TOLERANCEUNITS+METERS
&id=ISHAREdaf41704476c47fba251be7ccaa5e772

We have added some carriage returns to the above call to MapServer so that it is easier for you to see the elements described below.


Here we have a call to MapServer that contains a series of Layers. The layers parameter contains the list of Layers requested and then there is a series of map.layer parameters that contain the TOLERANCE, TEMPLATE and TOLERANCEUNITS for each Layer.

To identify the Layer that is causing the issue make a copy of the URL and remove half the layers. You can leave the associated map.layer parameters as they will be ignored. Paste the URL into a browser on the server and if the response is a series of numbers then it's processed successfully.

We can then rule out those layers as the culprit. Depending upon the success of the response you will need to either add or remove layers until there's a change in the response. Now we know which layer is causing the issue. We also have the location from the mapxy parameter and the radius defined by the TOLERANCE.

To find out where the data for the Layer is coming from use the Map Editor to find the LAYER and check the DATA entry to find which table holds the data.

Open up pgAdmin3 and connect to the relevant Server and Database and open a SQL Editor.

Use these values in the following query, where layer is the table name, x & y are the co-ordinates and tolerance is the value specified in the URL.

SELECT * FROM layer WHERE ST_Intersects(wkb_geometry, ST_Buffer(ST_GeomFromText('POINT(x y)', 27700), tolerance));

You should now be able to see the record(s) that contains the culprit data.

Investigating culprit data further

You may find reference to invalid character(s) within the iShare logs (e.g. webservice\logs\isharemaps.all.log);

[(null)] - XmlToDataSet entrance
2016-11-03 13:30:00,381 [10] FATAL MAL                                           [(null)] - Map Access Layer Exception:XmlToDataSet
Error when creating internal data set
'', hexadecimal value 0x0B, is an invalid character. Line 2310, position 196.

In the example above the '0x0B' is a non-printable escape character '\v' (also ASCII decimal character code 11). You will need to look at the individual fields within your PostgreSQL database to see which records contain the invalid character.

Using the select statement below (replacing 'yourtable' with the relevant table name and 'yourcolumn' with the potential columns that may contain the invalid character) search until results are returned.

Select *, regexp_matches(yourcolumn,E'\\v') from yourtable

(note: The \v escape character as per the above select statement  ...E'\\v'...).

Once you have found the fields and records that contain the invalid character the invalid character(s) will need to be removed. The best option may be to ask the source data owner/ source database administrator to remove the invalid characters from the source data prior to being imported for use with iShare.

My House returns extra results

This can happen for Show My Polygon layers where the TOLERANCEUNITS have not been specified as METERS in the LAYER definition in the .MAP file.

If this is set to PIXELS, which is also the default if no TOLERANCEUNITS entry exists for the layer, then it doesn't create the correct bounding box and, if the address is close to the border, can result in extra results being returned.

If the TOLERANCE UNITS are correctly specified as METERS the tolerance (distance) is hard coded at 0.01. So the result is that a one centimetre bounding box is used around the address location which makes for more accurate results.