Geo coding | DO NOT change the Field Names in conversion

[MichelleWilliamsERM]

This task takes much longer than it should, and I'm asking that Esri change the conversion code so that MY Field Names stay the same. Right now, all the Field Names change to USER_[My Field Name], which means that I must reconnect every field when I append.

Thank you in advance for making this a reality!

[KoryKramer]

Hi @MichelleWilliamsERM isn't this a duplicate request of the idea you posted earlier? https://community.esri.com/t5/arcgis-pro-ideas/geocoding-table-esri-renames-my-fields-would-you/idi-...

@ShanaBritt responded with helpful information about how to avoid what you're seeing.  Please let us know if that works for you, or if not, what specifically isn't working.  Thank you!

[MichelleWilliamsERM]

@KoryKramer yes it is, thank you for finding them both.

BUT this answer doesn't work for me, because I'm pulling data from a CSV file (with the the same names in the geodatabase). I designed it that way for ease of use.

Then I convert the lat longs,

and then I convert any addresses that didn't include lat longs,

then I need to APPEND to the geodatabase. 

Please let me know if this idea will be re-visited. I do this task a few times a month, and I can't be the only one.

[ShanaBritt]

@MichelleWilliamsERM If you geocode with csv table with the Minimal output field option, where in your workflow of appending data do you lose your original fields or have to delete fields?

[AZendel]

ESRI, please provide an option to exclude the very annoying USER_ prefix to all of the input fields!

[CMV_Erik]

This issue was raised in the comments of https://community.esri.com/t5/arcgis-pro-ideas/add-possibility-to-remove-all-quot-match-quot/idi-p/9... , but the post is marked Implemented, so I thought it might need its own post.

During geocoding, ArcGIS Pro adds a USER_" prefix to certain fields inherited from the original table/feature class. This behavior did not exist in ArcMap, and does not appear to be optional in Pro. I'm assuming this was added because it is necessary in some cases (maybe to proactively prevent field name conflicts?), but also causes new problems that did not exist before.  

Example: I was using a fairly complex ModelBuilder model in ArcMap that involved geocoding a text address in a point feature class and comparing it with the geometry to decide which one was better. A lot of steps in that comparison assumed the field names would be the same (including Merge and custom Python). I tried to migrate that model to Pro (2.9.1) and haven't been able to get it to work yet because I'm no longer working with two nearly identical sets of data. 

The ArcMap results already worked great, so rather than spend time redesigning or working around, I'd rather ArcGIS Pro perform the same as ArcMap. Even making adding the prefixes a default option would be fine; I don't mind unchecking a box when I need to. 

EDIT: https://community.esri.com/t5/arcgis-pro-ideas/geo-coding-do-not-change-the-field-names-in/idi-p/112... seems like the same issue

[CMV_Erik]

I opened https://community.esri.com/t5/arcgis-pro-ideas/keep-original-field-names-in-geocoding-results/idi-p/... before I found this. 

The same .loc locator produces different results in ArcMap and Pro. If I'm reading these threads correctly, the Minimal option might preserve the original attributes as desired, but it's only available in a narrow set of circumstances. 

Like @MichelleWilliamsERM I have a workflow that depends on preserving the original schema so I can recombine them (I use Merge instead of Append, but still fairly similar). There seems to be a lot of new requirements to retain the same proven functionality. Since it's a supported option in Pro, and the logic was working fine in ArcMap, it seems like it wouldn't be too hard to change the tool. Restoring the original functionality would save a lot of time and effort spent to work around it. 

[ShanaBritt]

@CMV_Erik If  you have created the locator in ArcMap you will not be able to use the output field options when using geocoding tools in ArcGIS Pro. You must create the locator in ArcGIS Pro with the Create Locator or Create Feature Locator tool , then you will have the option to maintain the original input table fields using the Minimal option when geocoding the table. Essentially, you will only get the option to maintain your original table fields in ArcGIS Pro 2.7 and later if you geocode with a locator created with the Create Locator or Create Feature Locator tool.

[CMV_Erik]

Hello @ShanaBritt,

I have read your responses related to this, and noted the server requirement you mentioned. To get the same results in Pro that I have now with the legacy locator in ArcMap, I would have to upgrade to Server 10.9, resolve the internal issues that have delayed me creating the updated locator, and allocate resources to create, test and publish the locator.  If I create a file locator that is only used within Pro, I would have to maintain both and could not expect same results, so I would have a new quality control problem. I could try add complexity to my model to try to rename the fields, but the new issues this created led me to post on this website rather than finish them. 

To summarize, the extra work described for ArcGIS Pro just restores the status quo in ArcMap, so right now there's no value in moving my model to Pro. My idea is for Pro to somehow preserve the status quo instead. 

[jzcgis]

Very frustrating that this has not been fixed yet. This creates a huge hurdle which results from esri not allowing for the unmatched from a local locator to be geocoded with the esri geocoder. The "USER_" creates a very annoying issue when trying to append the locally matched and the esri geocoded rows. Please fix this!

https://community.esri.com/t5/arcgis-pro-ideas/geocoding-table-esri-renames-my-fields-would-you/idi-...

https://community.esri.com/t5/arcgis-pro-ideas/add-possibility-to-remove-all-quot-match-quot/idi-p/9...