idea Locators: Why are suggestions different than Results? Make them the same. in ArcGIS Pro Ideas

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

Anonymous User — Thu, 12 Dec 2019 14:02:08 GMT

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!

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

BradNiemand — Thu, 12 Dec 2019 20:39:59 GMT

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

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

Anonymous User — Thu, 12 Dec 2019 20:59:27 GMT

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.

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

BradNiemand — Thu, 12 Dec 2019 22:22:15 GMT

Kevin,

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

Brad

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

Anonymous User — Fri, 13 Dec 2019 15:35:11 GMT

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)

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

BradNiemand — Fri, 13 Dec 2019 16:59:59 GMT

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

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

Anonymous User — Fri, 13 Dec 2019 17:27:09 GMT

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.

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

BradNiemand — Fri, 13 Dec 2019 19:14:39 GMT

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

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

Anonymous User — Fri, 13 Dec 2019 19:28:17 GMT

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.

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

BradNiemand — Fri, 13 Dec 2019 20:58:38 GMT

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

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

Anonymous User — Fri, 13 Dec 2019 21:45:22 GMT

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.

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

Anonymous User — Thu, 19 Dec 2019 19:19:52 GMT

Brad Niemand‌ Shana Britt I don't know if the ArcGIS Pro 2.4.3. update that just released reintroduced this bug it or if I am remembering wrong... I had thought this was fixed. It appears it does not work especially with Units.

I had thought it was working. I simply went to add Municipality and ZIP to the Pro Locator so it would display in the Suggestions so folks would know what muni a result is in. (as our address dataset usually has the most accurate data regarding municipality) However, I went to Create Locator and mapped all the fields (prefix, suffix, Unit, etc). Unfortunately we do not have state but we do have Municipality and ZIP. Pro 2.4.3. to server 10.6.1.

I noticed that it just plain doesn't work. It provides only one result. And no Units. This is a serious problem. https://cloud.sagis.org/arcgis/rest/services/Locators/Addressing_MAD_units_Production_Pro_Final3/GeocodeServer

I called Esri TS and we observed this inside Pro itself.

On the other hand, I had thought it was fixed as above at least with the Gazetteer but when I check the original Locator I published above with Gazetteer Locators/MADLocator_WithUnits_Production (GeocodeServer) with Enable Local Search (I enabled), it has the bug where it provides completely inaccurate addresses if you enter "1 East Bay Street" and click Enter for example. Way, way off in location, with results that aren't even spelled similarly.

So it appears either we have complete junk results when clicking Enter in certain rather common examples of what users would type OR we have no Units and only one single result.

Neither of these scenarios work for a usable locator. This has been logged as an "Enhancement". This is an urgent bug for us I hope is a hot fix or Pro update within a few weeks; compatible with ArcGIS Server 10.6.1.

I am again noticing after adding some locators to my server it's killing my AWS instance. All it does is three sites. Fairly large traffic but it has always been fine. Only increase in traffic since I updated a month or two back was adding locators with Suggest to it and now performance is abysmal. I will continue to investigate. I think that aspect would be solved if there was such as thing as Hosted locators. (our own locators hosted on AGOL)

I reviewed this thread Address point role with Units and we do not have unit types. At this point I do not have ability to add that, either. We need Pro / Server to work with Units and Suggest as soon as possible. I strive for diplomacy but frankly our customers are not pleased with these confusing issues in terms of simply finding an Address on an Esri viewer. Nearly every city uses Units and Suggest is expected now by users.

So for now, because Gazetteer supports Units and Suggest, even though in edge cases clicking enter returns wrong results I will stick with that, until the Pro locator is finally functional and debugged. The limit of only one result makes the Pro locator unusable. For example 7804 Abercorn St. It should return however many I ask for in Web App Builder. (I set it to 6 results for both suggest and return) so ideally it should provide all the various units at the Mall.

To recap, Suggest works fine searching "110 East State Street" Suggest: (Locators/Addressing_MAD_units_Production_Pro_Final)

...but no results are found from the Find Address Candidates. https://cloud.sagis.org/arcgis/rest/services/Locators/Addressing_MAD_units_Production_Pro_Final/GeocodeServer/findAddressCandidates?Address=110+east+state+street&Address2=&Address3=&Neighborhood=&City=&Subregion=&Region=&Postal=&PostalExt=&CountryCode=&SingleLine=&category=&outFields=&maxLocations=&outSR=&searchExtent=&location=&distance=&magicKey=&f=html

So, no good.

For Units it is even worse. Even Suggest doesn't work, at all. There are over a dozen Units that have the base address of 7804 Abercorn. However, if you search that from the Suggest page it returns only one, single result.

https://cloud.sagis.org/arcgis/rest/services/Locators/Addressing_MAD_units_Production_Pro_Final/GeocodeServer/findAddressCandidates

____________

Tech Support Reply:

Hello Kevin,

This is Afiq from Esri Support Services, writing in reference to case number 02462073. I have taken ownership of the case and will be working with you to reach to a resolution.

Thank you for your time for phone call and screen share session yesterday. Based on our discussion, I understand that you need assistance with the address suggestion from Locator in ArcGIS Pro Locate pan.

During our screen sharing session, we tried to create multiple custom locator using Point address roles in ArcGIS Pro. We created a custom locator with unit number but we were not able to find any suggested address by searching for the house number and street name. For example, when searching for 7804 ABERCORN ST, the Locate pane does not provide any suggestion.

Then, we proceed to create another locator without unit number and we were able to find the suggested address in the Locate Pane. However, we did not able to find a specific address point with unit number from the suggested addresses.

Furthermore, I created a sample address table from my end to geocode using the locator with unit number and I am able to geocode the address with 100 match score from my end. The addresses are as the following:

1037 Cornwall ST.
18 Silver Ave #3.
18 Silver Ave #4.
18 Silver Ave #5.
18 Silver Ave #6.

Thus, it seems like the custom locator is working perfectly fine. Then, I proceed to discuss the issue with a senior analyst from my end. Based on our discussion, it seems like the issue occurs due to the limitation on Locator with unit number to display Units in the suggested addresses from the Locate pane.

No worries as the issue has been logged as Enhancement to our developer team. The detail description of the Enhancement are as the following:

ENH-000124149 - Allow locators built with the Create Locator tool and a Point Address role to return candidates and suggestions for subaddresses when the base address is inputted.
Status : In Product Plan.

Since the status of the Enhancement is In Product Plan, the capability to display suggested address with subaddress or unit number in the Locate pane in ArcGIS Pro will be implemented in the future release. However, we would like to apologize that we are not able to perovide a specific time frame for the Enhancement to be implemented in future release.

I also would like to provide ArcGIS Ideas URL on "Provide Units in Suggested Addresses" as for your reference:

Provide Units in Suggested Addresses. (https://community.esri.com/ideas/17064-provide-units-in-suggested-addresses)

Kindly review and vote up the idea to help us to support the Enhancement request.

No worries as I already attached the Enhancement number to the case and you should be able view the status of the Enhancement through My Esri > My Organization > Support > Search for the ENH-000124149

Do let me know if you have any additional inquiries or information regarding to the case, you can reach me directly by replying to this email or calling Esri Support Services at (888)377-4575 followed by your case number reference and you will be routed to me.

Looking forward to your response.

Thank you,
Mohd Afiq Ikhwan
Esri Support Services

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

Anonymous User — Thu, 19 Dec 2019 21:47:44 GMT

When the Create Locator will be fixed to work with Units and Suggest; will it be possible in the next Pro release at 2.4.4?

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

BradNiemand — Sat, 21 Dec 2019 01:19:42 GMT

Kevin,

Adding support for suggestions for Subaddresses is on our list of work that we will be doing but it will not be in 2.4.4 nor will it be in 2.5 which is already dev-complete and will be release in early 2020.

I would like to provide some detail and background about the two operations, suggest and findAddressCandidates.

FindAddressCandidates is intended to be used with full addresses, not partial addresses. It does support partial addresses if the entire address portion is entered but the zones (city, state, zip) are excluded ONLY when you pass in either a location or an extent as a parameter to the API. Using either the location parameter or the extent parameter allows users to search without providing a zone. Another way to allow for no zones to be entered is to set the property I mentioned to you above, supportsOptionalZone = true, although this property was not implemented prior to 10.7 Enterprise so it would require that version or newer.

Suggest allows for not only partial address input but partial word input as well. You can enter "110 East St" (to use your example above) and get suggestions back that match that text input. The two operations are performing completely different functions but do work together hand in hand. The result returned from the suggest operation is passed in as input to the findAddressCandidates operation to give the user the address they asked for so if you were to pass in the text that you got back from the suggest call of which is "110 E STATE ST, SAVANNAH, 31401" you will actually get back the correct result.

The workaround that you are using to get suggestions back by using the Gazetteer will have limitations that you have mentioned above because that is not the intended use of that locator.

As mentioned above, we recognize that suggestions for Subaddresses is a feature that is important to your workflow and we are working hard to get that feature to you in a future release of Pro and Enterprise.

Brad

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

Anonymous User — Sun, 22 Dec 2019 02:42:45 GMT

All I can say is Suggestions and results from clicking Enter should be the exact same and Units should work. I hope locators will be a top feature update for 2.6.

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

GreggRoemhildt2 — Wed, 11 Mar 2020 18:18:06 GMT

Hi Brad Niemand - do you have any guides you can recommend for migrating from the "Classic" to the "New" locators?

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

ShanaBritt — Mon, 16 Mar 2020 22:20:31 GMT

Gregg:

Here are some details to be aware of when migrating from classic locators to new locators.

New locators are built with the Create Locator tool in ArcGIS Pro.
- How to create a new locator
  - It is recommended to create locators with administrative zones such as city, state, postal assigned in the field mapping. Region and region abbreviation are also important because they are used to help create different forms of state highways that are specific to each region or state. Not mapping them can impact geocoding quality and the performance.
  - All address elements should be broken up across multiple fields.
  - It is recommended to use polygons instead of point geometry when building a locator for administrative areas or when building a multirole locator that allows you to search for multiple locations with a single locator like street addresses, points of interest, parcels, and postal codes. Polygons also help to provide better reverse geocoding results. https://pro.arcgis.com/en/pro-app/help/data/geocoding/benefits-of-using-polygons-versus-points-for-areas.htm
- Can be used in ArcMap when published as a service from ArcGIS Pro to ArcGIS Server or Enterprise 10.6.1 or newer.
  - If Enterprise portal, then Share Locator.
  - If stand-alone (not federated) ArcGIS Server, then Publish Geocode Service.
  - Registering the folder that contains the locator as a data store with ArcGIS Server (federated/non-federated) before publishing the locator will help to reduce downtown when updating the service.
- Locators are built using locator roles instead of locator styles, an explanation of the locator role fields can be found here https://pro.arcgis.com/en/pro-app/help/data/geocoding/locator-role-fields.htm.
- A single multirole locator should be created instead of a composite locator in most cases.
- Suggestions validate the house number against the reference data.
- Suggestions are available for locators stored locally in the Locate pane in ArcGIS Pro as well as published as a service.
- Custom output fields can be easily added to the locator you create that reference other fields in the reference data used to build the locator that you want returned in the geocode results, such as fire districts, school districts, or voting districts.
- Output fields can be turned off and on in the locator properties to reduce the number of fields returned in the geocode result when batch geocoding.
- Locators that support multiple countries and languages can be created.

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

Anonymous User — Tue, 17 Mar 2020 13:37:15 GMT

Shana Britt‌ are results from pressing Enter and from Suggestions the same, with new newest Locators? (In my testing it did not seem that way)

I discovered a new reason this is a problem. In our Emergency Operations software webEOC, it relies on the method of pressing Enter to get the results array. It does not support Suggestions. I have found that Suggestions consistently provide more (ie better) results and possibilities. Can these two lists of results finally be unified? Or is there a way or option to do so? Thank you. The status of locators and lack of support for quality results with Suggestions for addresses with Units is a serious issue in multiple areas for us.

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

BradNiemand — Tue, 17 Mar 2020 15:51:42 GMT

Kevin,

As I previously described above, these two operations are different but do work together. The Emergency Operations software seems like it is using an old approach to populate geocoding results which is why you are seeing the results you describe. Using suggestions in combination with the FindAddressCandidates API (just pressing enter) is the approach that should be used and is used in all of Esri's interactive clients for geocoding. It seems like the Emergency Operations software needs to updates to use the interactive geocoding approach of using suggestions in combination with the FindAddressCandidates API.

With regards to suggestions for subAddresses, there is work being done to support this in the near future.

Brad

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

Anonymous User — Tue, 17 Mar 2020 17:58:58 GMT

Hi Brad, do locators still not support subaddress Suggestions in 10.8?

At the end of the day, for us, results from both methods need to be identical. At least as an option. Users have said they do not like having different results from the same locator, it has been a problem since 10.3. At least in our viewers and for any and all of my applications, the results need to be identical from both methods of searching.

Meantime, yes, we need Suggestions for subAddresses and to not to get weird results in wrong locations (I know, that is a limitation on the 'classic' locators; but, they're still the best locators because they work with suggestions and subaddresses, and we will continue using them even with issue of different results from suggestion/Enter and sporadic wrong location from Enter) Also meantime I may begin exploring https://blog.batchgeo.com/open-data-open-source-geocoders/