Batch geocoding using CSV file in ArcGIS Online produced incorrect results

[GeorgianaBostean]

I geocoded a .csv file of 22,000+ addresses in ArcGIS Online by publishing the file as a hosted feature service (and accurately specifying the fields to be used for geocoding). After doing a spatial join of the points to a polygon in Desktop and zooming to an arbitrary location, by chance I realized that within one city (City of Vernon) the 9 locations were geocoded to 2 points. I am concerned that this may have happened with other points.

Any thoughts on what I may be doing wrong and suggestions on how to verify that the geocoding process is happening without errors, other than to manually check individual points?

I called ESRI support and they were not able to figure out why this occurred, except to suggest that I take out the spaces in the column headers (there was one space in the header for the address field). I don't believe this is the problem because when I uploaded the file with just those 9 rows, but without editing the column headers to eliminate spaces, the points geocoded correctly.

I'd like to figure out why this occurred-- I have large files with 100,000 rows to geocode and need to make sure (and find a valid way to verify) that they are geocoding correctly.

The screenshot of the table with the 9 rows selected (the space in the column header visible for the address field) and the map zoomed to the two points: 

[GeorgianaBostean]

Thanks so much for your reply. I couldn't find a way to direct contact you with the case number, Katie Cullen. Is there a way to do that through GeoNet or can I e-mail you?

[Anonymous User]

you can email me at kcullen@esri.com

[Anonymous User · Accepted solution]

I spoke with the analyst who owned this case and I was able to get a copy of the data. I found that I could only reproduce the issue with the 9 records in Vernon being geocoded to two locations when I did not manually map the Licensed Locations field as the address field. This must be done manually because the geocoding dialog does not do it automatically. The fields that were mapped automatically were City, State, Zip and Zip4.

My testing involved publishing two services with this data, one with the address field mapped and one without. What I found was that when the address field was not mapped and there were two locations for Vernon there were 8 records at one point and 1 at the other point. These were based on zip code.

With both feature layers added to a map I got a better idea of how close to accurate the points were located without an address. In some situations, the locator matched without the address which is pretty impressive. In other cases, it got very close because it located down to the 4 digit zip extension.

If we look at the locations in Pro using the locate pane we can see detailed information down to what level the location matched. This is noted in the AddrType field. When the address is provided it matches down to AddrType: PointAddress and if it is not provided it matched down to AddrType:PostalExt which is still very precise.

Here is a video demonstrating how you can see that information.

I want you to feel confident that the World Geocoding Service is extremely reliable and accurate. You have my email, please feel free to reach out if you have any further questions.

[GeorgianaBostean]

Thank you for troubleshooting this, Katie, and sending a thorough response on how you did so. It was helpful to understand how you compared the files, how the matches are completed, and how to check what the match was based on (is that possible in AGOL or Desktop since I don't use Pro?). I was sure that I did specify those fields, but who knows.

Thank you again for following up.