Geocode Output Schema Difference in Pro

1066
9
08-20-2018 12:29 PM
MichaelVolz
Esteemed Contributor

I am working on updating python geocoding scripts, that have run in ArcMap for years, to Pro.  I was able to Rebuild Address Locator and Geocode Addresses, but it appears that the schema of the output has changed between ArcMap and Pro.  Is it expected that the Address Locator can be used in both ArcMap and Pro, but the output generated from geocoding the addresses has a different schema in Pro than in ArcMap?

0 Kudos
9 Replies
ShanaBritt
Esri Regular Contributor

Michael:

Which version of ArcMap were the locators originally created in? Which version of Pro are you using?

ArcMap 10.5 / ArcGIS Pro 1.4 was the release where the address locator styles changed, which included additional output fields. Some of the Python changes are described in the following blog. Geocoding Improvements and Deprecations in ArcGIS Desktop 10.5 and ArcGIS Pro 1.4 

The address locator styles included with ArcMap and ArcGIS Pro are the same and the expectation is that a locator created in ArcMap will work in ArcGIS Pro and a locator created in ArcGIS Pro with the Create Address Locator tool will work in ArcMap. There may be times where the locator style included with ArcGIS Pro is more current than the one installed with ArcMap because the two applications are on different development cycles. A problem might be found in ArcMap after its cycle ends, but we are able to get the fix in the Pro. Then the following ArcMap release will include the fix. At version ArcMap 10.6.1 and Pro 2.2 the styles are the same.

0 Kudos
MichaelVolz
Esteemed Contributor

Shana:

The address locator I am using has a style release of 10.3.  As such, is it expected behavior that the geocode results of an address locator with a style release of 10.3 would have a different output schema in ArcMap 10.5.1 compared to Pro 2.2.1?

0 Kudos
ShanaBritt
Esri Regular Contributor

Michael:

Any locator with a style release prior to 10.5 will have less (different) output fields than a locator created with style release 10.5+. Style release 10.5 is when there was a major change in the styles, especially the Single House Subaddress style. The change at the time was to add the improvements that had been made to the online World service to the out of the box styles and fix performance issues with the Single House Subaddress style. The locator styles included with ArcMap and Pro have the same style release.

0 Kudos
MichaelVolz
Esteemed Contributor

I'm running the same address locator in both ArcMap 10.5.1 and Pro 2.2.1, not using 2 different address locators.  So I'm asking if running the same address locator in ArcMap 10.5.1 and Pro 2.2.1, should I get different results?

I could understand if I run an address locator with 10.3 style the results would be different from running an address locator with 10.5 style, but that is not the case in this particular scenario.

0 Kudos
ShanaBritt
Esri Regular Contributor

If you are using the same 10.3 locator in ArcMap 10.5.1 and Pro 2.2.1 you should be getting the same results, the output fields will be slightly different where ArcMap will have "Arc_" fields, which are used during the geocoding and rematching process. Pro will have "IN_" fields, which are equivalent to the ArcMap "Arc_" fields and "USER_" fields, which are the original fields from the input address table. See the first paragraph under the image in this Pro topic About geocoding a table of addresses—ArcGIS Pro | ArcGIS Desktop and in the ArcMap topic About geocoding a table of addresses—Help | ArcGIS Desktop 

0 Kudos
MichaelVolz
Esteemed Contributor

That is exactly what I am seeing as the difference between the results in ArcMap 10.5.1 and Pro 2.2.1.

If I upgraded the address locator to Style release 10.5, would the output results also be different between ArcMap 10.5.1 and Pro 2.2.1?  I am asking this because I have some python based scheduled tasks running in ArcMap 10.5.1 and I was hoping to port the scripts over to Pro without making major changes (Other than those specificied in ESRI documentation) such as accounting for schema differences in data generated during this processing.

0 Kudos
ShanaBritt
Esri Regular Contributor

Michael,

The difference in the output schema between ArcMap and Pro is not caused by the style, it is a difference in the underlying code for when the output feature class is created between ArcMap and Pro regardless of the version of the desktop application. When you geocode with ArcMap regardless of the version of the locator style you will get "Arc_" fields and with Pro you will get "IN_" & "USER_" fields in the output feature class.

You may want to check out this topic for converting your 10.x scripts to ArcGIS Pro. 

http://pro.arcgis.com/en/pro-app/tool-reference/data-management/analyzetoolsforpro.htm

0 Kudos
MichaelVolz
Esteemed Contributor

When I click on your link it says the site cannot be found.  Can you check on this link yourself?  This problem occurred with another link I was given in GeoNet as well.  I was able to find the location that I believe you were trying to point me to:

Analyze Tools For Pro—Data Management toolbox | ArcGIS Desktop 

When I ran this tool on the script I run in python 2.7 with ArcMap, it did not inform me of output schema changes that would need to be considered.  I think this would need to be an enhancement to this script.  As with some other changes between python 2.7 and python 3.x, it will probably just require manually making the changes, as the tool will not find all the differences between python when migrating from ArcMap to Pro.

0 Kudos
ShanaBritt
Esri Regular Contributor

Michael:

The link I copied from my post worked for me. The script is checking for functionality that is not supported in ArcGIS Pro, but the topic does include links related to converting from Python 2 to 3 such as https://docs.python.org/3/library/2to3.html and tips for migrating from 10.x to Pro. Python migration from 10.x to ArcGIS Pro—ArcPy Get Started | ArcGIS Desktop. the GeocodeAddresses gp tool has no parameters regarding the fields in the output feature class, so modifying the feature class related fields would have to be manual.

0 Kudos