geocoder Suggestions list in Search should not contain addresses that don't exist

Anonymous User

Idea proposed: The geocoder Suggestions list in Search should not contain 'ghost' addresses that do not exist.

In the auto-complete Suggestion list it provides ‘ghost’ addresses that do not exist and are completely out of range, whether a point locator or centerline locator.

A thread that touched on this was...

https://community.esri.com/message/787096-re-composite-locator-not-properly-locating-address-points?...

Regardless of styles, composite, etc. it applies across the board. Bottom line is, end users find it frustrating that auto-complete will suggest a result, which looks ‘real’, then you click it and it says No Results Found. It should not Suggest anything that doesn’t exist. If it’s a point locator, it should be an exact match, the same array literally. If it is centerlines it should at least be within a block range. Now, how they accomplish fixing this could be a variety of ways. They could for example do a validation on the backend or the API and remove ‘ghost’ addresses that do not exist out, or simply make the ‘result’ list the array that is also passed to the ‘suggestion’ list. I understand the indexing, looking at various parts of the geocoder, street, unit, house number etc. But I cannot see a business case for suggesting addresses in the Suggest list that don’t exist.

Ironically, it worked perfect with 10.2 and WAB 1.x for auto complete. In fact I shoved the WAB 1.x Search widget into WAB 2.1 viewers for a while and it worked great when we had Server 10.2. But when we updated to 10.5.x and 10.6.x it stopped working with the old WAB widget and I had to use the new one that worked with ‘Suggest’. So, the old auto-complete worked fine. Now, this functionality is problematic. My only thought for an alternative is I’ll turn off autocomplete until it can get fixed. It would be unfortunate because autocomplete is a nice feature.

RyanKelso · ‎10-29-2018

We recently discovered this issue with invalid address suggestions and it is a bummer to have to decide between potentially misleading/confusing users with blatantly incorrect information vs. disabling a feature that can be genuinely helpful. It's hard to believe that they decided it was a good idea to roll out the suggestion feature without at least some kind of validation performed on the address numbers.

I must have loosened the minimum candidate score and spelling parameters so much that we don't see 'No Results Found', but you can end up with a very unexpected result in comparison to what the suggestions were indicating.

I definitely support this idea of eliminating suggestions for addresses that don't exist. It's poor implementation. Some kind of "address number out of range" message could be helpful to inform the user of the problem because as much as I don't like how the suggest engine works, the user does have some responsibility for plugging in bogus addresses, or reporting the problem in the case they've found an error in the address data.

Anonymous User · ‎10-29-2018

this may have users questions data accuracy.. If it suggests one thing via auto-complete, but then says "poof, no addresses found" when you click it, they are left wondering "is this database correct?"

Ryan, your idea would be perfect. A simple "address out of range" popup message would be great. And if in fact the citizen knows it should be right, as you note, they should call their local city GIS to get to the bottom of it and get it added. But for now, I had to simply disable auto-complete entirely. Would be really nice, once this gets fixed.

Anonymous User · ‎03-22-2019

Team Esri: Will ArcGIS Pro 2.4 work for publishing the fixed locator (where Suggest works correctly) to Server 10.6.1? I ask because we may not upgrade until Server 10.7.1 and so I am hoping we can finally squash this bug, when we get Pro 2.4 and publish to our Server 10.6.1.

DEWright_CA · ‎04-01-2019

I would be worried about this proposal; with each version of Pro being tied to the current/latest version of Enterprise you might find that a location built in Pro 2.4 not being fully supported backwards to 10.6.1. I have found that comparing the Locator template xml file shows some major differences.

Anonymous User · ‎04-03-2019

In that event I'd look for other software as an address locator.

Anonymous User · ‎07-12-2019

2.4 Locator with or without subaddress, to 10.6.1 Server and it still creates ghost results. I tried Create Locator and Create Address Locator. And the 'match out of range' option. Still ghosts. I'm going to give up using locators for address points and just use Feature Layer search in the WAB Search widget. It finds units nicely with Exact Match but without ghosts. It also does not have the bug where if you find an address, but then it goes in to all caps in the WAB widget, you click it to search again and it says No Results.

Anonymous User · ‎11-01-2019

Shana Britt‌ I am still seeing this in Pro 2.4.2 to 10.6.1. It comes up with a ton of garbage results and somewhere in the middle of the list is the only real address, 1 E Bay. I tried this again today. https://cloud.sagis.org/arcgis/rest/services/Locators/MADunit_Suggest/GeocodeServer

I called TS. They said this is still an open issue, even for ArcGIS Server 10.7.1 Enterprise.

I had thought; ok, well, I will just stop using Locators altogether and point the Search widget at the address point featureLayer. It works great, absolutely perfect. It does not produce garbage results that do not exist and it works well with units. (because in our Full Address field it points at the Unit is there). However, one problem. Once I deployed this county-wide, the load has made it perform slow when many people use it at once. Despite being on a compacted SDE dedicated to this one layer and service. I suggest (pun intended) that this be elevated rapidly for a fix in the next version of Pro. At some point I will update the Server (at this point, probably waiting for 10.8) however, this fix should be able to be resolved by patching Pro and/or Desktop. It is of that caliber of importance, it can not wait longer, or for server upgrades, which organizations do more slowly than for Desktop and Pro versions.

this is priority 1 for us for Esri now. (now that I have seen the featureLayer search can't sustain load)

MaenKhamis · ‎11-01-2019

Previously, for performance reasons, house number (or unit number in the case of US Address - Single House Subaddress style) was not used in suggestions' capability.

The implications of this is that, while house numbers are displayed in generated suggestions, they are not validated until a Geocoding request is sent.
Therefore, if the house number typed by the user does not exist, it will be displayed in suggestions but will not be returned from Geocoding results.

A best practice when creating a custom locator with suggestions enabled is to create a Composite Locator with at least a Street Address or Point Address locator and a separate Street Name locator.
Doing so will ensure that if the house number doesn't exist in the Street Address or Point Address locator, you'll get a fallback match to Street Name.

Please note that the the maximum number of participating address locators in a composite locator is 30, but it is recommended not to use more than 10, otherwise geocoding may be significantly slower.

I hope this sheds a light on this issue and gives the users a little more flexibility in reducing the ghost addresses being generated in the suggestions drop-down list until we address this issue permanently.

Thank you,

Anonymous User · ‎11-01-2019

Thank you Maen for your research thus far. We only want the Address layer for the Locator, as the difference between the two locators has caused confusion. Hopefully we can figure out a workaround or hear of a commitment to fix this in a Pro and/or Arc Desktop update.

DEWright_CA · ‎11-01-2019

Maen Khamis‌ I think you should preface that example with the "Street Name" locator to say if your business case allows. Since this has the potential if not used/applied properly to create significant location issues that the user trying to look for a address may not realize.

For example; State Highway can run for 10s or 100s of miles, and span multiple jurisdictions; so not finding a Point Level or Interpolated Address Range location and rolling down to the given Street Name could have you off spatially but a significant margin.

Now as GIS Practitioners we get that; but a casual/non-GIS user who is using a app in Portal or even ArcGIS for Office who geocodes a list of addresses may not get that nuance.