Broken Standardized Addresses

Question

Here is new issue with ArcGIS Pro 2.2.x. I have a table that we run the Standardize Address tool on each month and then geocode and extract from. We are finding a interesting scenario happening. When the value going into the "Single House" or "Singe House with Subunit" locator type such as this: 399 W C ST We see the house number, the "W" PreDir, "C" StreetName, and "ST" SufType parse back. But then in the same table we have: 399 W H ST But in this case we get the "W" direction, but the "H" goes into PreType, then the "ST" into the StreetName. This is a major issue that will break many things for states that build and support Sales Tax Data. Bruce Harold‌ / Brad Niemand / Agatha Wong / Shana Britt who would run point on this question? If you look at the attached fGDB, you can see the source table; as well as the results from Desktop 10.6 and Pro 2.2; it looks like Pro 2.2 using the Single Address with SubAddress did the best job; but I will have to do a broader test tomorrow with more records to see if more scenarios show. GeocodeTest.gdb.7z.zip SarahHartholt_1-1645115372507.png

dewright_ca · Answer

If you take a look at the file I attached to the original question you can see a bit of a comparison. Yes, Single Address is problematic in the small sample I uploaded; I am pulling our full sample DB right now to compare our 14.5m records to look at a broader scale across the software.

Yes, Standardize the street-address field for data processing separate of Geocoding; we (and 23 other states) are required to provide data in this format (link) based on the schema in Chapter 5. So having nominally standardized addresses is key. For years we have been able to use the tools in ArcGIS to meet this need and have guided other states to use the same process because it was very consistent; but we are finding more issues now and where we had thought it may have been bad data coming in; it is looking more like the changes/enhancements in ArcGIS maybe a leading impact.

Yes, I am happy to sit down with your folks at UC, I believe Nathalie Smith our of the Olympia Office was already trying to schedule a meet again since it seems a annual touch-base is good for WA and your group.

BradNiemand · Answer

David,

We made some modifications to the "Single Address with SubAddress" standardization for Pro 2.2 and 10.6.1 and it looks like from your updated post that this may have fixed your issue, is that correct?  Also, are you saying the "Single Address" style still has this issue?

I am still a bit confused as to what you need to provide in #2?  Do you standardize the input tables or something else?  The process of geocoding parses out the street components and returns them as output fields and because during this process it can compare multiple permutations against the reference data to figure out the best result, the results will be much better.

Maybe I still don't understand the requirement but standardization isn't a perfect science.  It can be prone to errors which is why we really have been steering users away from it and toward using geocoding as that process instead.

I will also be at the UC so maybe we can sit down and talk about this.

Brad

dewright_ca · Answer

Hi Brad,

1. We had seen similar or mixed types of issues I believe with 2.1 and ArcGIS Desktop 10.5.1. I haven't tried yet running the process again in 10.6; was kind of holding for 10.6.1 to just see the most stabilized version; but also knew that before I head to UC I wanted to take and prepare some benchmark data for discussions.

2. We are required to provide CSV and Tab files quarterly for various data outputs based on ranged-street data and those structured to look the USPS formatted outputs. So we use the Standardize Address tool to format the bulk table content that we are able to then do a select distinct on the various column selections for those files.