nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

'US Address - Single House' Not Using Zipcode Field

MarcCusumano

I have been running multiple passes of geocoding to match ~1.4m service points to a layer of ~3.6m parcel polygons using the "US One Address + Zone" address locator in 9.3.1 with much success. However, after recently switching to ArcGIS 10, I have found that this address has been replaced with 'US Address - Single House'.

It appears the same, as the new style has an option to specify 'Zip Code', but after reviewing the results I have found that the Zipcodes in the Match_Addr field almost never match the Zipcodes in the original table. This means the geocoder is matching addresses in the wrong place, even for matches with a score of 100%.

I decided to narrow the selection for the geocoding tool and created an address locator specifying a selection of zip codes in a single county and running a pass of geocoding using a selection of points from the same zip codes. Even with this narrow selection the tool moves the points into the wrong postal boundary. The value in the "Score" field will be 100 because the addresses are the same text string but the zip code is different. Here is how this is set up:

The address locator is made from a parcel polygon layer which has civic number (PROPERTY_C), street name (PROPERTY_S), and Zipcode (POSTAL).

The service points layer has a single address field (ADDRESS) and a zipcode field (ZIPCODE).

I feel the geocoding score should be significantly lowered if the zip codes do not match. Is there a way to force the geocoder / address locator to match by zip code first and then attempt address matches? This would make the review process and QA / QC much easier.

By the way I was looking at making a composite locator but this does not seem to be what I am looking for (and besides that the tool produced an error and failed to run).

Any help would be appreciated.

Vind meer berichten getagd met

Accepted answers

All comments

VlatkoRoland

Regarding SCORES and matching, can you please explain on the practical example why the score goes from 0 to 100 by changing only one letter in the name of the street?

US-single house LOCATOR (spell sensitivity 90% and also tried with 60%)
House number: 18
Street name : GLAGOLJASA
City or place : SPLIT
ZIP code       : 21000

Address data to geocode
Street : 18 GLAGOLJASKA
City    : SPLIT
ZIP     : 21000

Please note letter K in address (misspell)
After geocoding result score is 0 !!!!!!
During rematch I have removed letter K and score became 100

At least, because of ZIP code and City name result should score more than 0

Do I miss something?

JonHancock

Hello Marc,

As a side note, keep in mind that in MultiNet ZIP boundaries do not necessarily line up with edge ZIP codes (because ZIP boundaries are generalized, mainly for aesthetic reasons). As a result, it is possible to geocode with a perfect ZIP match and still fall outside the ZIP boundary.

Jon

MarcCusumano

Thank you for your timely response, Brad.

The address locators I am using were built by myself yesterday. I built three separate address locators:

-One using the latest TeleAtlas street routing data, using US Address - Dual Ranges (v10 locator) and US Streets with Zone (9.3.1 locator)

-One using a polygon feature class of parcels. using US Address - Single House (v10 locator) and US One Address with Zone (v9.3.1 locator)

-And finally one using our customer service points, using the same locators as as the parcels.

The locators have worked great for 347,000 out of 360,000 features which is great. My frustration has arisen in trying to get the final 13,000 features geocoded. I will look into the documentation you provided. Thank you, I'll let you know how it goes.

BradNiemand

Hello again, I'm still encountering this issue of the address locator / geocoding tool giving high scores (even 100) to addresses matched in the wrong zip code. If possible I would have these matches receive a score of zero as they are incorrect. I am running ArcGIS v10.0 (Build 3200) with SP2. All patches are installed including the "geocoding memory leak" patch.

Also, when building an address locator from TeleAtlas street data, the geocoding service will use the zipcode field to some extent, but will still place very high scores (>95) for matches in the wrong postal boundary. I have to run a spatial join on a postal boundary layer and do a select by attributes to find the matches in the correct zip codes, which always eliminates over 95% of the matches.

Also, the process seems to place low priority to Suffix and Prefix Type. An address of "12th St" will be matched with "12th Ave" and be given a very high score (>90). Also "N 12th St" will be matched with "S 12th St" with a high score (>90).

Basically it seems the only field the address locator places any weight to is the street name and civic number.

By the way I am not using composite locators of any kind.

Has this issue been resolved? Is there a way to force the address locator to use these fields to validate a match? The geocoding functions worked wonderfully in 9.3.1 which makes this a real shame.

*EDIT* I have imported the address locators from 9.3.1 and am experiencing the same issues.

I guess I have a few questions and a couple comments.

1. You stated in the first paragraph above that zipcode did Not seem to have any influence in the score. What locator were you using? Was it one that you built yourself? If so, you would need to rebuild the locator in order to get the benefits of the Service Pack improvements that were made to the locator styles.

2. At ArcGIS 10, we changed the way that we handle scoring. We now use a weighted score to determine the total score of the geocoded address. If you haven't see the PPT slides from the user conference, I would suggest you take some time to look at them because they go a bit deeper into the way that scoring works at ArcGIS 10(UC 2011 Geocoding Technical Workshop Presentations).

This might explain why the weight of the PreDir and StreetType is less than you expect it to be.

Possible Solutions:
1. Raise the minimum match score so that the geocodes don't return unless they have a much higher match score.
2. Customize the style to modify the weights to fit your needs. You can take a look at the following document to get an idea of how you would approach doing this (Customizing ArcGIS 10 locators (An Esri Geocoding Technical Paper)).

I hope this helps.

Brad

MarcCusumano

Hello again, I'm still encountering this issue of the address locator / geocoding tool giving high scores (even 100) to addresses matched in the wrong zip code. If possible I would have these matches receive a score of zero as they are incorrect. I am running ArcGIS v10.0 (Build 3200) with SP2. All patches are installed including the "geocoding memory leak" patch.

Also, when building an address locator from TeleAtlas street data, the geocoding service will use the zipcode field to some extent, but will still place very high scores (>95) for matches in the wrong postal boundary. I have to run a spatial join on a postal boundary layer and do a select by attributes to find the matches in the correct zip codes, which always eliminates over 95% of the matches.

Also, the process seems to place low priority to Suffix and Prefix Type. An address of "12th St" will be matched with "12th Ave" and be given a very high score (>90). Also "N 12th St" will be matched with "S 12th St" with a high score (>90).

Basically it seems the only field the address locator places any weight to is the street name and civic number.

By the way I am not using composite locators of any kind.

Has this issue been resolved? Is there a way to force the address locator to use these fields to validate a match? The geocoding functions worked wonderfully in 9.3.1 which makes this a real shame.

*EDIT* I have imported the address locators from 9.3.1 and am experiencing the same issues.

BradNiemand

I would first recommend installing 10.0 SP1 and see if that solves your issues.

Brad

AndrewDecker

Not sure if this post (from below) is relevant to you but found it interesting as I'm investigating something similar. There is a bug with zip codes in locators in 10.

I was going to recommend troubleshooting it and leaving out zip code all together but...

http://forums.arcgis.com/threads/26294-How-to-use-Single-House-Dual-Range-Option-without-using-Zip-field

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.