Geocoding Service with suggestions enabled returns invalid matches

[ChrisCarter]

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

[m_neer]

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

[ChrisCarter]

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

-Chris

[AnthonyKobah]

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.

[ChrisCarter]

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

[AnthonyKobah]

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.

[ChrisCarter]

Good to know I'm not just seeing things! 

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

[AnthonyKobah]

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.

[AnthonyKobah]

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.

[ChrisCarter]

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

AddressPointGeocoder (GeocodeServer)

-Chris