Geocoding Service with suggestions enabled returns invalid matches

5550
30
08-21-2015 04:09 PM
Highlighted
New Contributor II

I have a 10.3 geocoding service with suggestions enabled which is based on address points.  The endpoint can be accessed here:  http://gis.anaheim.net/arcgis/rest/services/AddressPointGeocoder/GeocodeServer

Everything works correctly except for the suggestions, which seem to be returning invalid matches.  For example, if you test the Suggest functionality here:  http://gis.anaheim.net/arcgis/rest/services/AddressPointGeocoder/GeocodeServer/suggest and type in 1240 E Diana, you get 3 suggestions:  http://gis.anaheim.net/arcgis/rest/services/AddressPointGeocoder/GeocodeServer/suggest?text=1240+e+d...

but only one is valid (1240 E Diana Ave). 

Where did the other two come from?  Maybe I am misunderstanding how suggestions work, but I expected the geocoding service to query the data on the fly and only present valid matches.

-Chris

Reply
0 Kudos
30 Replies
Highlighted
by
Occasional Contributor

ArcGIS Online Health Dashboard  yesterday there was issues, perhaps this may be the cause?

Reply
0 Kudos
Highlighted
New Contributor II

Thanks, but I'm not using the ArcGIS Online geocoding service, I am using one that is hosted on my own server.

-Chris

Reply
0 Kudos
Highlighted
Occasional Contributor

Hi Chris,

Looking at your Geocode service, the other two streets do exist. "E Diana Dr" and "E Diana Pl".

Suggest generates a list of SUGGESTED matches for the input text". "E Diana" is very much a valid input. That to me explains why you see the other two. E_Diana_Dr.jpgE_Diana_Place.jpg

Reply
0 Kudos
Highlighted
New Contributor II

Hi Anthony,

Thanks for your response.  You are correct; we do have a Diana Place and Diana Drive.  So if I asked for suggestions on 'E Diana', I would expect to get those results.

However, when I ask for suggestions on '1240 E Diana' (as a user would type in), I would expect to see only one match, as Diana Place and Diana Drive have different address ranges (2500 blocks).  In my opinion, the suggestions do not work correctly.

Another example, if you search for our City Hall (200 S Anaheim), it gives suggestions that include units 10, 101, 102, etc.  But these units do not exist.  This makes it very misleading to the user because it implies that those are valid addresses/matches.

-Chris

Reply
0 Kudos
Highlighted
Occasional Contributor

His Chris,

Thanks for the reply.  I tested the Geocode Service in a Web App Builder Application and I now see the behaviour you described. It does present the other two Suffixes (Place and Drive). Clicking on them leads to nothing as they aren't valid candidates.  The question then is why do those two show up if they are not valid options.

Can you share a screenshot of the Address locator properties. The "Geocoding Options" to be specific.

Reply
0 Kudos
Highlighted
New Contributor II

Good to know I'm not just seeing things! 

Here are the geocoding options for the address locator in question:

Reply
0 Kudos
Highlighted
Occasional Contributor

Hi Chris,

Thanks for that. The problem doesn't happen with the World Geocoding Service. Am only seeing it with your service.

This requires more testing to narrow down the issue. Could you increase the "Minimum Candidate Score" to 80, Republish the Service and then query execute the query to see what gets returned.

Reply
0 Kudos
Highlighted
Occasional Contributor

Hi Chris,

Thanks for that. The problem doesn't happen with the World Geocoding Service. Am only seeing it with your service.

This requires more testing to narrow down the issue. Could you increase the "Minimum Candidate Score" to 80, republish the Service and then execute the query to see what gets returned.

Reply
0 Kudos
Highlighted
New Contributor II

Ok, the service has been republished with the MinimumCandidateScore set to 80, and it is still behaving the same way.

AddressPointGeocoder (GeocodeServer)

-Chris

Reply
0 Kudos