Select to view content in your preferred language

Add ArcMap parity to composite locators with multiple primary fields

892
6
04-18-2024 06:54 AM
Status: Open
Labels (1)
JohnNergeBrooklynPark
Frequent Contributor

Seeing if there's any larger demand for this capability. Originally this got logged as a bug but was resolved as As Designed. Recently confirmed with Esri support that they are not planning to reach parity with this ArcMap capability.

In ArcGIS Pro, it does not appear possible to create multirole or composite locators that allow you to use different primary fields. The specific use case we had in the ArcMap days was using a composite locator to first attempt to geocode a table using an address field and then falling back on the parcel number if that failed. This was really helpful when geocoding data from non-spatial systems because while the parcel numbers were usually right there could be typos or errors in the address since they were hand typed. Here's an example of a dummy table we might get.

AddressParcelTableSample.jpg

In ArcMap composite locators, you can specify multiple primary fields and determine which locators use which of those fields. So using the data sample above, we'd have the address point locator use the ServiceAddress field to geocode and the parcel locator use the ParcelNumber field.

ArcMap Composite Geocoding.jpg

In ArcGIS Pro, whether creating a multirole or composite locator, it does appear this is possible. I'm wondering if this is a problem for other people and if you have any use cases or other scenarios where you need to geocode using multiple address, parcel number, POI, common name, or other such fields?

I  should note that I was able to find a workaround by creating a feature locator for the parcel instead and using that in the composite locator. This ends up being clunky though because the locator still defaults to single field, and then when switching to multiple fields it lists all of the address inputs and a generic Name field at the end that is not intuitive to know that's where you should add the parcel ID field.

6 Comments
ShanaBritt

@JohnNergeBrooklynPark It is possible in Pro to do what you are looking for, it just requires a different workflow in formatting your data. The service address and parcel number should be in the same field in the table and this field should be mapped to the Address field when you geocode the table with your multirole locator that contains PointAddress or StreetAddress role for the street addresses and Parcel role for the parcel numbers.

ShanaBritt_0-1723215368317.png 

ShanaBritt_2-1723217525069.png

 

 

 

JohnNergeBrooklynPark

So that would technically work, but that's not really how our data are stored. That screenshot was meant to make it obvious which addresses are valid or not, but in reality we're geocoding tables with thousands of records, and we won't know before running them which ones will match to an address, street, or parcel ID ahead of time.

Also sometimes the data is in house and other times it's from a third party. So what we really need is that ArcMap style functionality where you can geocode using multiple primary fields so that if one fails the other can still be used further down the composite locator hierarchy.

shildebrand
ShanaBritt

@JohnNergeBrooklynPark @shildebrand , I was able to figure out a different workflow using the Rematch Addresses pane to address geocoding a table formatted like below using either a multirole locator or a composite locator of locators created with the Create Locator tool. In this case the multirole locator would use the  PointAddress and Parcel roles. 

ShanaBritt_0-1764174422471.jpeg

https://pro.arcgis.com/en/pro-app/latest/help/data/geocoding/rematch-locations-converted-from-a-tabl...

1. Geocode the table with the multirole locator using SingleField, mapping the ServiceAddress field.

2. Open the Rematch Addresses pane and Select Add or Modify Locator from the Locators drop-down menu.

3. Map the Single Line Input field to the ParcelNumber field. This maybe the IN_ParcelNumber field depending on what Output Field option was chosen when geocoding the table originally.

4. Click the back button to go to the main pane

5. Click the Menu burger button > Predefined Queries > Unmatched Addresses or create a custom query. 

ShanaBritt_1-1764175351087.png

6. Click the Auto Rematch button to rematch the selected records.

JohnNergeBrooklynPark

I appreciate the workaround, but it's not really gonna work for most of our workflows because if we're doing any rematching it would be against our locators, not the world geocoder.

The workaround I mentioned in a previous post still works, I've even been able to use it as a geocoding service in Survey123 for Address input fields to allow for autocomplete on either an address or park name, for example.

ShanaBritt

@JohnNergeBrooklynPark The workaround I suggested does not involve using the ArcGIS Geocoding service, you would be using your custom locators for rematch in the Rematch Addresses pane. Step 2 allows you to use the existing locator and just map a new field to use for geocoding or you can select a brand new locator for the rematch/review workflow.

There is no way around having extra input address fields when the composite consists of a locator created with the Create Locator tool and the Create Feature Locator tool. If you removed the extra input fields when building the composite locator, the locator would be invalid and not work as expected. 
Having more context for how you are using the locator in your workflows helps to better understand  your needs and identifying a suitable workaround.