idea geocoder Suggestions list in Search should not contain addresses that don't exist in ArcGIS Pro Ideas

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

Anonymous User — Tue, 23 Oct 2018 15:57:00 GMT

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?commentID=787096#comment-787096

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.

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

RyanKelso — Mon, 29 Oct 2018 20:07:46 GMT

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.

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

Anonymous User — Mon, 29 Oct 2018 20:21:53 GMT

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.

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

Anonymous User — Fri, 22 Mar 2019 15:36:58 GMT

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.

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

DEWright_CA — Mon, 01 Apr 2019 16:47:15 GMT

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.

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

Anonymous User — Wed, 03 Apr 2019 18:39:19 GMT

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

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

Anonymous User — Fri, 12 Jul 2019 13:26:15 GMT

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.

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

Anonymous User — Fri, 01 Nov 2019 16:32:41 GMT

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)

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

MaenKhamis — Fri, 01 Nov 2019 19:37:25 GMT

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,

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

Anonymous User — Fri, 01 Nov 2019 20:09:14 GMT

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.

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

DEWright_CA — Fri, 01 Nov 2019 23:16:57 GMT

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.

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

Anonymous User — Sun, 03 Nov 2019 17:51:05 GMT

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?

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

Anonymous User — Mon, 04 Nov 2019 17:32:39 GMT

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.

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

Anonymous User — Tue, 05 Nov 2019 14:14:07 GMT

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.

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

DEWright_CA — Tue, 05 Nov 2019 19:33:48 GMT

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.

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

Anonymous User — Thu, 07 Nov 2019 15:24:40 GMT

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)

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

Anonymous User — Wed, 11 Dec 2019 20:51:16 GMT

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.

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

BryanReist — Thu, 14 May 2020 13:40:39 GMT

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!

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

Anonymous User — Sun, 17 May 2020 17:10:16 GMT

Bryan Reist‌ awesome glad to hear it!

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

PrestonDallas1 — Wed, 01 Jul 2020 16:16:37 GMT

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