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.

[Anonymous User]

David, indeed.

I would put forth that the locator simply should never Suggest a non-existent address (for points) or never Suggest an address out of range i.e. that is not possible (for street centerlines with ranges).  It should also display a tooltip or message telling the user that the address does not exist (points) or is out of range (centerlines).  As you have described quite cogently, sometimes governments do not want to use a Composite due to confusion it causes. This is a vital issue to address for the platform in the next update across products.

Last, this is connected to a related Idea.  We should be able to disable Suggestions one at a time, in the WebApp Builder's Search widget.  Why? Because I specifically want to be able to suppress the Esri world locator service Suggest, in the event that I disable it for my local locators.  Or perhaps I want to include Centerlines, but disable the Suggest for it and leave Suggest only active for the Address Points.  (I would like to do that.)  Kory Kramer‌ this would be so helpful to be able to disable Suggest on a per-locator basis in WebApp Builder's Search widget.  It would also be good to be able to disable it via a URLparameter (for other viewers and apps not based on WAB), for example '&Suggest=false'.   Esri world geocoder service - disable Suggestions?   

[Anonymous User]

another idea: display the working progress indicator ↻  while Search widget in WAB is waiting for responses. It does show this, if you hit Return, but it does not show this while it is awaiting responses for Suggestions, but it should.  Users will wait a few seconds, if they know they should be waiting.

[Anonymous User]

With Locators essentially broken now on Enterprise for years, I decided as a stop-gap I'll use some credits and try publishing a locator on AGOL so it will support Suggestions and Units, and I'll script replicating to AGOL. 

To my surprise AGOL can't do locators. And it's not In Product Plan?!  That is also surprising.

 ArcGIS Online Hosted Locators 

This would even generate revenue, considering that it is Hosted.  I may have to look for another platform to locate results if this is not fixed by 2020.  

[DEWright_CA]

Yes, I have talked at UC about this a couple of times. The answer I got was to host a feature service and query against that. Explaining that you can't do the level of search logic with that work flow as a geocoder/locator would seemed to fall on deaf ears.

I think the reason there is AGOL relies on PostGIS as a backend much like Portal does; so there is no real geoprocessing backend like you see with AGS.

[Anonymous User]

Another bug I have found.  the "rooftop" URL parameter does not work for the Suggestions results from the World Locator Service.  This is a bug introduced in the October AGOL Update and confirmed by TS. This is relevant because I have the world locator in my address list and because of the dysfunctional state of locators, this is sometimes the only locator that returns results.  And I wire it to click the result, to click the parcel, in www.sagis.org/map (if you click the result it fires an onclick of the of the map to show the parcel popup. Thus the address needs to be in the parcel! Usually it is close enough but sometimes, since 'rooftop' parameter is now broken, it will be in the street or even the wrong parcel)

[Anonymous User]

Update:::: I think we have a fix for many users and use cases. Use the Gazetteer style.

To recap: Locators were broken after 10.2; Suggest began to produce 'ghost' results as documented above with Suggestions.

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

Composite Locator Not Properly Locating Address Points 

At first I thought, I'll use some credits and put the Locator on AGOL, thinking a locator on AGOL might support Suggestions and Units, as AGOL is the leading edge of development. And then I'll just script replicating to AGOL.  To my surprise AGOL can't host Locators. It is not In Product Plan either, which was also unexpected. Hosted locators could generate revenue from storage credit. ArcGIS Online Hosted Locators 

Update:::  Big thanks for our Rep Rob Hathcock‌!  So the solution is to publish as Gazetteer style Locator. Since our address point layer has a field Full Address where all info is concatenated, it works perfectly!  Really forgiving with spelling, like for units, prefixes, etc. Best of all?  No 'ghosts'!   So it's finally all good, at last.  I don't know what magic it has under the hood but it seems far less sensitive to spelling. I have noticed one issue, of the difference in Suggestion vs hitting Return (magickey vs no magickey) which I will post a separate question about. That is a separate issue and an inherent design feature enhancement I have for the locator product team, to make them both behave the same and return the same result array. 

I would still love to host our Locator on ArcGIS Online for speed purposes and to offload some bandwidth. And it would generate Esri credit revenue.  And for those without the luxury of using a single field the Ghost result bug is still a key issue for the Locator product team.

David Wright‌ - I had rolled our viewer www.sagis.org/map out a few weeks ago. So while directly querying the featureService from the Search Widget worked well in testing, the server load was too high when deployed to production and it took nearly a minute at times to get results. Even after I set minChars to 7 so as to reduce requests. (out of the box it is at only two characters; and generates a ton of requests because of this by default) So it was not usable. I immediately moved the data on to ArcGIS Online as a Hosted layer and re-pointed the site to it, and then the performance was great once again. However, we noticed the spelling is very sensitive in this way, as you have noted David, in terms of search logic. 

So, I have now spun up a locator with the Gazetteer style and it looks we have finally gotten a locator that works well.  It is fast, no ghost results, and resilient and forgiving handling of spelling.  

[BryanReist]

I cant say thank you enough! I have been working on a new locator off and on for weeks. The false suggestions were giving a lot of our users problems and it was driving me crazy. Adding a Gazetteer locator into my composite locator and only enabling suggestions on the Gazetteer fixed my problem immediately. Well done!

[Anonymous User]

Bryan Reist‌ awesome glad to hear it!

[PrestonDallas1]

I can confirm it works with the Gazetteer Locator.  I needed to create a field that had a full address (city, state and zip code included) but once that was done and the locator pointed to the full address field, it got rid of the ghost addresses.  I completed this in ArcMap 10.6.  Thanks for the suggestion!

Preston

[BradNiemand]

Locators created with the Create Locator tool in ArcGIS Pro only give suggestions for valid addresses.