Composite Locator Not Properly Locating Address Points

[mpboyle]

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.

System Details

• ArcGIS Desktop 10.3
• ArcGIS Server 10.3
• Address locator style = US Single House with Subaddress

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.

[Anonymous User]

we use single field: Folder: Locator 

[ShanaBritt]

Here is some additional information related to this thread.

This limitation is mentioned in the documentation here towards the bottom:

Creating a composite address locator—Help | ArcGIS Desktop 

Here is the Note:

The suggest index does not store the house number for performance reasons, and so the best practice is to create a composite locator with at least a Street Address or Point Address locator and a Street Name locator. The reason for this is that if the house number doesn't exist in the Street Address or Point Address locator, you will still get a match to Street Name. You do not need different data to create the Street Name locator. A Street Name locator can be created from Street Address data because the Street Name style only uses a subset of the fields required by Point Address or Street Address.

We have also made fixes to our online service for this and plan on rolling these out to users when creating locators on their own data later in 2018.

Shana

[Anonymous User]

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.

[ShanaBritt]

Kevin:

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.

What is the reason you use the Single Field locator style for address points vs US Address—Single House and Single Field locator style for centerlines vs US Address—Dual Ranges ?

[Anonymous User]

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!

[ShanaBritt]

Kevin:

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

http://desktop.arcgis.com/en/arcmap/latest/manage-data/geocoding/commonly-used-address-locator-style...

-Shana

[Anonymous User]

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. 

[ShanaBritt]

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.

[ShanaBritt]

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.  

[Anonymous User]

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.