Locate Addresses with Units

[BryanLynn1]

I have created a locator using the Point Address Role. The locator works but it will not locate or provide candidates for addresses that contain units. For example: 606 Main St will work but 606 Main St Suite 150 will not. This is a big problem when all of the addresses on a parcel have unit addresses. For example: 10001 Kingston Pike only exists with units (e.g. Suite 100 - 150) and since all the address points have unit values it will not show up in the candidates list.

[DMOB17]

Our jurisdiction also needs to be able to enter a complete address and then be prompted with subaddress units without having to type out the first character of the unit. We fraction our addresses in an alphabetical way for certain locations (123 Main St., 123 Main St. A, 123 Main St. B, etc...) so the suggestion feature as it currently functions is unfortunately useless in providing suggestions for these addresses since you'd need to type out the first character in the unit name, which in our case would be equivalent to just typing out the entire address with the unit. We're hoping for someone to be able to type out 123 Main St. and be shown a list of 123 Main St., 123 Main St. B, 123 Main St C, etc. If they have to type as far as the first unit character then they'll never see any suggestions.

All attempts to create a single house - subaddress locator in catalog have shown very strange errors and "ghost" suggestions for addresses that don't exist. It adds on unit values for addresses that don't have any. I've been down the Gazetteer path but unfortunately some third party vendors use our locators and expect to see more information returned by a locator than a Gazetteer style provides. 

[ShanaBritt]

@DMOB17 To avoid those ghost suggestions you would need to build a locator using the PointAddress role in the Create Locator tool in ArcGIS Pro. The suggestions returned by locators created with the Create Address Locator tool in ArcMap or versions of Pro prior to 2.7 did not validate the house number or unit to the street name and this is why the "ghost" suggestions occur. What information are they expected to see returned from the Gazetteer style locator? The Create Locator replacement for that would be the POI role.

If you have not created locators with the Create Locator tool before, 3 tutorials were added for the 2.9 release.

• https://pro.arcgis.com/en/pro-app/latest/help/data/geocoding/tutorial-create-a-locator.htm
• https://pro.arcgis.com/en/pro-app/2.9/help/data/geocoding/tutorial-create-a-multirole-locator.htm
• https://pro.arcgis.com/en/pro-app/2.9/help/data/geocoding/tutorial-create-a-locator-with-more-than-o...

[ShanaBritt]

We've added the ability to return a list of subaddresses and a summary of  subaddresses at an address after typing the base address to ArcGIS Pro 3.0. A feature that represents the base address is required in the reference data used to build the locator in order for the new functionality to work. A locator with the new settings enabled must be created in ArcGIS Pro 3.0 and published to ArcGIS Enterprise 11.0 . The new properties, " Show summary of subaddresses with base address suggestion" and "Suggest when base address is typed" are disabled by default and the number of suggestions displayed can be configured in the Locator Properties dialog on the Performance page. If you are part of the Early Adopter Community or have access to ArcGIS Pro 3.0 Beta1  you can test out the functionality and provide any feedback. If you were to go through the create a multirole locator tutorial , you could test the new functionality with the following addresses:

- 1508 CIRCA DEL LAGO, SAN MARCOS, CA

- 1616 CIRCA DEL LAGO, SAN MARCOS, CA

[ScottFedak2085]

I'm happy to see the attention that the ESRI locator team is paying to subaddressing, so thanks!

In our municipality / county, there could be parcels where all official addresses contain subaddress data and a base address feature doesn't actually exist. I have built in "dummy" base addresses into locators in the past to ensure that searches will still hit on a more geospatially accurate Address Point instead of falling back on road centerlines. This would be an identical workflow to what you prescribed in your explanation, and building in these Base Address features isn't too difficult.

However, maintaining these base address features does necessitate additional and somewhat unnecessary steps into a workflow when my goal is usually to try and simplify workflows as much as possible. I'm not sure how wide of support there would be for this, but building in functionality to ensure a base address is searchable via locators even though it may not exist in the authoritative data could help streamline peoples data workflows a bit, and every little bit helps.
 
Thanks again!

[DanMcCoy1]

We try to maintain these "dummy" base addresses as well, but sometimes they get missed.  It would be great if they weren't required to get subaddresses to show up as candidates.

@ShanaBritt , do you know why the "feature that represents the base address is required in the reference data used to build the locator in order for the new functionality to work"?  It seems unnecessary from a user point of view.  Perhaps, the next enhancement could be to remove that requirement....?

Glad we got this far.

Thanks,

Dan

[BradNiemand]

Dan,

Thanks for the feedback.  There is no requirement (although it is recommended) to have a base address when using partial subaddress suggestions or even when requiring the entire subaddress to be entered in order for the suggestion to be given.  This is also true for searching without suggestions.  The base address is only required for the new features that show a list of subaddress suggestions or the subaddress info.

The reason that the base address is required for showing a summary of the units at a base address or a list of the subaddresses at a base address is because the base address is what triggers this functionality.  The base address must exist for this to work.

There are also challenges with just adding a base address at build time.  There would have to be assumptions made when building the locator in order to add the base address at build time and could cause unexpected or even erroneous geocoding.  This is why the base address is required for this new functionality.

Brad

[DanMcCoy1]

Thanks for the info Brad.  It's kinda hard to wrap my head around until I see it in action, I guess.... 

 Also, I'm going to have to read up on what's meant by adding an address at build time.

[BradNiemand]

Dan,

What I mean by "adding an address at build time" was potentially adding a checkbox to the Create Locator tool to allow for the point address to be added when building the locator.  As mentioned above, there are some challenges with that approach that could cause unexpected or even erroneous geocoding results.

Brad

[DanMcCoy1]

ah, gotcha.... makes sense.  thanks 🙂