Locators: Why are suggestions different than Results? Make them the same.

1381
19
12-12-2019 06:02 AM
Status: Open
Labels (1)
KevinMacLeod4
Frequent Contributor

Brad NiemandShana Britt

I posted in the other threads, it looks like I have Locators figured out and working now with Suggestions and Units by using Gazetteer. You had suggested this initially for other geocoders e.g. parcel IDs but I have found it works great with house units.  

However, there is still one problem. This appears to be an issue with the way Locators work in general.  If you start typing, you get different results in the Suggestions array than you do if you simply hit Enter to submit the request. This has to do apparently with the magickey.

I will provide an example.  Let's say someone searches for '1 East Bay Street' on my property viewer www.sagis.org/map If you start typing it, the result comes up perfectly (it is actually 1 E Bay in the full address, but the Gazetteer is great, in that it is forgiving with spelling).  However.... if you paste it in or type it quickly and hit Enter... Nope.  No results found. It does find a record as you will see but that's from a completely separate locator which searches by Owner Name. It finds '501 East Bay Street LLC'.  

And remember the Ghost results bug still exists i.e. you can't have a Units locator with Suggestions which for those not fortunate enough to have a single field with Full Address to use for Gazetteer is still a roadblock to using a locator at all.

This is conceptually similar. Suggestions be exactly the same as hitting Enter. No 'ghosts'. And no leaving out correct results as I have found here. I understand the idea was to try to accelerate the result retrieval but I think that these issues trump that in 99% of cases. Perhaps it could be an option to still use the old Enter result retrieval (with its leaving out of some results, like in this post) and perhaps you could leave a legacy style of Locator with Ghosts but I want some way of fixing both of these bugs/product design issues.  For me, I would never choose to have the Results from Enter differ from Suggestions, at all, in any case. It must be the same. Locators are the most important part of nearly all my viewers. Thank you for understanding, and for your continued conversation on locators!

Tags (1)
19 Comments
BradNiemand

Kevin,

You should really migrate over to new locators that are created with the Create Locator tool in ArcGIS Pro.  The classic locators have a limitation to them where the house number is not used as part of the lookup for the suggestion.  The new locators do not have this limitation.

Using the Gazetteer locator with the classic locators for address suggestions will have the limitations to it.  As you can see by the output, it will prefer matches that have more exact matching components and which is the case you mentioned above is indeed "501 East Bay Street LLC".  The abbreviations and other parts of address matching are not done the same in the Gazetteer locator.

I believe that the solution you are looking for is already available to you but it just requires migration over to the new locators created with the Create Locator tool in ArcGIS Pro.

Brad

KevinMacLeod4

Hi Brad, I tried them. Ghost results still, from Pro 2.4 to Server 10.6.1. Your reply about a month ago I think you said the Units subaddress locator still can't do Suggestions without the Ghost bugs right?   I see Suggestions now as basically an essential interface component; as people expect it.  We need units as like 99% of other cities using locators for addresses, we have a units field and it is essential.  

Gazatteer works great.  This issue I found here is really the only problem with it, other than that it's perfect.

The lack of results in the Enter results array issue is actually not too big of a deal, because most times, now that the auto-complete Suggestions are fast and accurate, people will use them. Some people may still have hitting the Enter key ingrained though.

Locators with Suggestions and Units worked great in 10.2. Locators are not an area of GIS that has changed or will change.  It just needs to work fast, reliably, and be easy to use.  Maybe slightly better prediction or speed over time, but not at the expense of bugs like the Ghost results array; lacking results from Enter; or other issues.  So... when Esri adds Hosted Locators as a capability to AGOL - please add Gazetteer. Or something that works like it. After a long time of testing fortunately our rep let me know about Gazetteer or we'd really be a in a bad spot because of these locator issues.  While the featureLayer search (not using locator just the layer) on AGOL as a hosted layer worked fast enough, it was far more stringent with spelling than Gazetteer.  And for now Gazetteer works great.

This was more of a tip for the product team to take Gazetteer from doing 90% of what we need to 100% if Enter would simply return the same results array as Suggest.  (I'm sure I could tweak the widget to force it to request the results as such but I try to keep customization to a minimum to ensure maintainability, and there is more than enough I have modified throughout the stack)  I needed a solution immediately for production and fortunately our rep let me know about the Gazetteer.  

At the end of the day, this is a general concept. Irrespective of locator style. Results from the Suggestions array vs the Enter key should be identical. Always. Ghost results should not be returned. And the Enter array should not be missing results. 

BradNiemand

Kevin,

What "Ghost" suggestions are you seeing with the new locators?

Brad

KevinMacLeod4

Brad Niemand‌ thanks!!  I would like to say, thank you for getting me to give it one more go!

It does in fact work great now -  ArcGIS Web Application  I just give it a test. 

I tried Create Locator a month or two back and was still getting ghost results, i.e. out of range results that would say No Results Found when you clicked on them.  It appears the update fixed it. Or I may have used Create Address Locator,  It looks like I'm ready to switch over to the new Pro Locator.

However, it seems the core question of this thread is still an issue. If I type in '1 East Bay Street' or '1 East Bay' it comes up in Suggestion.  But... it does not come up, if I hit Enter. No Results Found. Can the Suggestions array be unified with the Enter key array? (I put forth Suggest array be used for both as it catches and returns more results as it is more forgiving with spelling)

BradNiemand

Kevin,

That is great news!  I would still like to dig in on your final question though.

If I type in '1 East Bay Street' or '1 East Bay' it comes up in Suggestion.  But... it does not come up, if I hit Enter. No Results Found. Can the Suggestions array be unified with the Enter key array? (I put forth Suggest array be used for both as it catches and returns more results as it is more forgiving with spelling)

I think I know what is happening here.  The locator does not support searching without one zone (city, state, zip).  When you are retrieving suggestions, the application is passing in the location (center of the map) to resolve what location you are at but I assume during the findAddressCandidates call the location is not getting passed in as well which it should be.  When location is passed in, it acts as a zone for the locator and it should really be passed in as well if it was passed in to the suggest API.  This is why there is an inconsistency.  Whatever parameters get sent to the suggest API call should also get passed into the findAddressCandidates call.  Is this a default Web App Builder app with no custom code?  If so, it might be something I can see if we can get resolved going forward.

I have a workaround for you though without having to write any code.  There is a property (which will be exposed in the UI for 2.5) that allows a locator to search with no zones.

NOTE

This property is not intended to be used with locators for large areas.  Typically we would suggest that it is used with cities that only have a single unique postal code because there is the potential for identical addresses across multiple postal code which could lead to false positive matches.  This will also affect performance with larger locators.

In the UI it will be named "Match with no zones" and have a value of Yes or No.  You can manually add this property to your locator by opening the locator .loc file and adding the following property to the file.

supportsOptionalZone = true

I think this will solve your problem but just let me know.

Brad

KevinMacLeod4

Brad, thank you again for bearing with me. I appreciate it! This is probably a helpful discussion for many folks with address locators too, so I'm glad we're doing a deep dive.

So I have a few questions first. I was not aware of this zone component until now. When you say zone (city, state,zip).... I have city and ZIP enabled. I left out state because it seemed redundant and I wanted address results in Suggest to be concise.  However, if I simply enable State (i.e. it will say GA for them all) would that ... make it work and pass Zones from hitting Enter?  Also I am hesitant to apply the mod since you mention it is for one postal code and we have a dozen, and moreover it is 150,000 points across an entire county on a resource constrained server. So I am thinking, as a trade-off it may in fact be better to leave it be versus apply the mod. 

Question, regarding the Zones.  So you're saying Enter is behaving as it should, and it is Suggest that is not? Or the other way around.  Because I like the way Suggest works. I do not like how hitting Enter does not find 1 East Bay.  Are you saying if this patch is applied to Web App Builder; then both arrays (Suggest and Enter) will be the same?  I want them to both find the exact same results, for unification of user experience, and also so that hitting enter finds things such as 1 East Bay and 1 East Bay Street.  However that is accomplished under the hood. I was thinking it was in relation to the magickey, which is I suspect how this zone info is passed. Because I noticed Suggest has no magickey and Enter has it in the URL along with WKID and other spatial info.  

BradNiemand

Kevin,

Your locator is built with zones which is good.  We would also suggest including State when building the locator as well because we use the state values to enhance highways to account for variations for highways.  For example STHWY 101 would also accept GA 101 even if the alternate name wasn't in the data.

Locators, by default, require at least one zone when performing geocoding.  A zone can be one of the following in the USA:  City, State, Zip or you can alternatively pass in the current location of the map.  The last option is to enable matching with no zones in the locator which is the optional property I described above.  Although we discourage using this property for large areas, I don't think your area is too large to consider it and the performance effects will likely be minimal.

With regards to default behavior of searching by pressing Enter or using suggestions, they are both the same.  The problem here is the suggestions IS passing in the location as the center of the map and the Enter search IS NOT.  If they were both consistent, then they would provide similar results.  What I was mentioning as something that would need to be done in the Web App Builder is to change the underlying code to ALWAYS pass the same parameters to both methods.

Are you saying if this patch is applied to Web App Builder; then both arrays (Suggest and Enter) will be the same?

 

The answer to your above question is yes.  If both operations passed in the location of the center of the map, the results would be the same.

Brad

KevinMacLeod4

Hi Brad, awesome. Then yes, hopefully the WAB Search can be updated to behave in this way. Thanks for that explanation, I'll add the state to it.

BradNiemand

Kevin,

I just created an app that points to online and captured the network traffic and it looks like location is getting passed in for me.  What web browser are you using?  If Chrome, can you hit F12 and tell me if the findAddressCandidates request has a location with it when just hitting the Enter button?

Also, when you configured your app did you "Enable local search" on it?

Brad

KevinMacLeod4

Awesome.  That did it.   I had to enable Local search. Now it works perfectly!!  It finds the result from Enter just like Suggest. Thanks again Brad, seems like my idea can be safely said to be Implemented. I'll clean up my cross posts on it.