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.
Do you get the same behavior with the Subaddress point locator in ArcMap that you do with the published service in the web app? Does the same behavior occur when the point locator is based on the US Address - Single House style and published to ArcGIS Server?
The locator seems to work fine in ArcMap, but not within a web application. We have found that using the same locator published to a 10.4.1 Server works as expected, i.e. locates the address correctly.
I had a similar issue with invalid address suggestions returned by the Web App Builder Search Widget when used with a custom Geocoding Service that used Address Points as one of its match sources. Having a "Suggest" option that returns addresses that do not exist in the underlying match source is just not helpful. So, I do not use the "Suggest" option with my Geocoding services.
I submitted Case# #01810750 "Web App Builder Search Widget provides suggestions that do not exist the source data" on 7/30/2016. The enhancement "#ENH-000098678 [Enhancement] Add options in the Create address Locator tool to include parameters to alter the index (xml) allowing full address strings, custom names, or other information to be provided rather than the default index" was submitted based on this case. The above enhancement includes the following related bug: Related bug : BUG-000094346 - The 'suggest' operation of the REST application programming interface (API) returns a suggestion for invalid street addresses that do not exist.
The suggestions that are returned for geocoding services are only suggestions for the street name and do not include suggestions for the house number as a suggestion index for the house number is not generated when the address locator is built. The house number suggestion that you see could be any house number that is valid for features that has the same street name. If the geocode service is based on the Single House Subaddress style, you will get suggestions for the subaddress, but the subaddress suggestions are not correlated to the house number. You would also get subaddress suggestions that are valid for the street name, for example, if you had point features that represented 123 e main st with subaddresses A-F and 150 e main st with subaddresses A-D, then typed in the address "150 e main st " to get suggestions for the subaddress , the subaddress F would show as a suggestion because it exists at 123 e main st. This is because the subaddress is not correlated to the house number, but F is considered a valid subaddress for the street name suggestion of "e main st". At version 10.5 if you select the invalid subaddress is selected in the map viewer no results are returned and if used in ArcGIS Pro, no candidates will be returned in the results list of the Locate pane. This behavior is as designed.
BUG-000094346 - The 'suggest' operation of the REST application programming interface (API) returns a suggestion for invalid street addresses that do not exist.
It seems that suggestions that have not been validated as legitimate addresses should not be suggested. Maybe the development team should consider this from a user perspective. Clicking on suggestions that go nowhere is a waste of time.
Development is aware of the limitation in the current technology regarding suggestions for geoocde services and have plans to address the behavior in a future release. Currently, the suggestion index is only built for street name and no suggestion index is built for house number or subaddress unit. Because of this, there is no correlation between the street name and house number or subaddress unit.
Thank you for the reply. This may be a difference in terminology, but this is not a "limitation". Returning invalid suggestions that link to no result found is a massive bug from alot of our standpoints. In fact, it makes the the locator unusable as is. Instead of "a future release" I would hope it would be addressed as soon as possible.