We have a composite geocode service that is not properly locating address points. If I enter an address within the search bar of one of our apps built with WAB, the address will show in the suggestions, but if I click on it, I will be taken to somewhere that is not the address that's listed. And, in some cases, the address is not listed at all in the suggestions box.
There are other locators within the composite locator that are working, for example, one of the locators allows the ability to search by parcel number. This locator is working fine. Another allows you to search by place name, and again, this one is working fine.
I have already deleted and re-created the address point locator (with Suggestions enabled), and re-published the service. Still getting the same results where addresses are not locating properly.
Below are a couple sample searches. The first 2 screenshots show that when searching for an address, it appears that the suggestion is finding the address, but will take you to the wrong location. The second 2 screenshots demonstrate that the locator using place locations is working.
Any ideas what the issue is with our address locator and why it is not working properly?...why it's not locating at the correct location?
1) Searching for 1801 Whispering Pines Ct SW Cedar Rapids IA --- shows in the suggestions box.
2) Search result when I click on the suggestion. I'm taken to 1720 Whispering Pines Ct SW.
1) Searching for Linn County Community Services Building --- shows in suggestions box. Search fails.
2) Search result takes me to the correct location. Search works.
It happens in locators that are plain locator with a single layer, like a singleField for our address points or singlefield for Centerlines. It also happens in a Composite of them both.
The new locators that you will be able to create will not have what you described as a "ghost address" when typing and suggestions are returned. I'm not sure if they will address the problem in WebApp Builder or if WebApp Builder is a separate issue. What is happening in the current locators is that when you create the locator with suggestions enabled the street name is indexed, but house numbers and subaddress units are not indexed, so there is no correlation between the street name and the house number or subaddress unit. So when you type a house number that does not exist for that street segment, the locator returns an invalid suggestion candidate from a line segment in the reference data that does have a house number of 149. I believe we fixed that part where you click on the invalid suggestion and it zooming to a different location at either version 10.5.1 or 10.6.
Hi Shana - can we expect a fix for Server 10.5.1? It happens for us in 10.5.1. We did 10.5.1 for the upgrade this year not 10.6.x on our main server. Meantime I'll test and see if it happens on our 10.6.1 on Amazon. As to the address and locator structure I will look in to that but as I am local gov't it's likely a matter of working with legacy systems and workflows. Perhaps we can spin up a new locator style to test though and I will look in to it. Thanks for the replies again!
I'll need to search for the bug report to see which version the zooming behavior was addressed for the locators, it might have been specific to the Single House Subaddress style, but will double check. I would definitely move away from using the General - Single Field locator style as it acts as a lookup of exact matches and doesn't use the same indexing, parsing, and spelling sensitivity logic as the US Address locator styles. Also, the Single Field locator when built with suggestions causes a memory leak on server and would suggest using the General—Gazetteer locator style for searching for place names, points of interest, well IDs, parcel numbers, etc... that are not address house numbers or street intersections. See the 'Applications' column in the table of the commonly used locator styles in the following topic
Hi Shana, thank you... Ah yes, I saw that in another thread about bugs in Server 10.5.x. i.e. Geocode Service with Suggestions Enabled Issue
Can we expect a hot fix or patch for that for Server 10.5.1 though? Meantime I will discuss with other departments about the idea to have a different locator style. Thank you for the details on this. But realistically it will probably be a long-term transition.
Our current plans do not include a hotfix or patch for Server 10.5.1 for the General - Single Field style based locator with the memory leak as there is a workaround of using the Gazetteer locator style that has better logic than the Single Field style.
Just an update on the status post 2018 User Conference...
The ArcGIS Geocoding team is currently working on a solution for improving suggest results for locators organizations build from their own data. We are targeting the solution for release for the first half of 2019.
Shana Britt Thanks for the update! Does it get rid of the "ghost addresses"? What I mean is, I search 149 Smith St and let's say it only goes to 140 on that block. It returns a 'ghost' result that when you click, then changes to No Results Found. Confusing for end users. Also the bug where if, let's say you even leave the entire address the exact same, in the geocoder entry box in WAB, or modify it slightly, and hit Return again, it won't find it. You have to type it again. I think that's probably more related to WAB's widget. Locating addresses is one of the first things users do with a map viewer, it's literally the entry point. Thanks for letting us know that it's being addressed. Yup that was a bad GIS joke.