Can't get geocoding to work without Zips

[katherinehayman]

I'm trying to geocode historical addresses for Manhattan and Brooklyn that do not include zip codes. Based on the instructions in this other thread: http://forums.arcgis.com/threads/136...ut-knowing-ZIP , I made a dual range locator (using Tiger 2010 lines, Kings and NY counties merged) and left the zip fields <none>. When running the geocoding process, I left the zip field blank again. None of the addresses match up at all- no errors, just 100% failure. To make sure my addresses were okay, I filled in a few zips and ran again using a similar locator that did include the zip field- those addresses with zips geocoded fine.

What do I need to do to get all of my addresses to geocode successfully, without zipcodes? I'm running the trial version of Arc 10 which is supposed to have been updated with all of the service packs.

Thanks.

[jborgion]

Just a shot in the dark Katherine, but is the dual range locator appropriate? Perhaps the US Streets would be a better choice? I'm not too familiar with the tiger street format.

[katherinehayman]

US Streets is what I would have used in 9.3, but it doesn't seem to exist any longer- do you know the equivalent? The dual is used when the side of the street matters, and I used it since the Tiger lines include that information.

[jborgion]

It's in there; for whatever reason ESRI 'simplified' the choices in v10. Take a look at an earlier thread of mine. You may need to add some 'phony' fields...

[katherinehayman]

I've tried adding a field of nulls, a field of single-digit " "s, and a field of 5-digit dummy zips (for example, 11111) to both the reference file (which does have the correct zips) and the address file to be geocoded, both separately and at the same time. Nothing seems to work- the only difference is that instead of having a 100% failure rate, nothing happens when I tell it to geocode- it just returns a 0% rate for successful, unsuccessful and tied. The geocoding seems to rely on the zip since it returns no suggestions if the zip is wrong even by one digit.

[jborgion]

Arrgh! It might be time to hoist the white flag and give tec support a call. Maybe Brad from ESRI is lurking about out there to lend us a hand.

[Shawn_Sumpter]

I am having the same problem. I created an address locator (US Address Dual Ranges) using our county's street centerline data which includes street name, to-from fields and right and left zips. After creating the address locator, if I use the direct geocoding tool on the geocoding toolbar for a single address (example 916 Sunset Dr) it finds the addresss correctly. If I geocode a table of information using the street address field only (field content example "916 Sunset Dr") I get a 100% failure. If I designate both the Street Address field and the zip field when geocoding, I get something in the range of 85% success rate. However, even though the right left offset is designated at 20 feet and the workspace units are feet and there is no reference scale set, the points created in the geocode reflect no right left offset. The points appear directly on the centerline.

This is just weird!

[katherinehayman]

I figured out a solution: my Tiger city field said "061" for NYC and the field I created in my address table said "61" since Arc automatically removed the zero. Apparently when geocoding without zips as many of the other fields as possible must be EXACT matches to produce candidates, and without the city being an exact match I was getting 100% failure.

I did a number of tests using a very small sample of data and streets and found that as long as all possible fields (to/from addresses on left and right, city, state, and street name) were filled in when creating the locator, it didn't matter if the zip field was designated, left blank, or filled with a set of false zips. However, when only the required information was filled in (to/from addresses on left and right and street name, I believe- Arc is currently frozen so can't make sure), the geocoding failed because it was unable to make a match just based on street addresses themselves, even within a single city. I didn't test to see if both city and state were needed, but I assume that they are, or at least that city was more necessary than state, since everything failed when my two city fields were not exactly the same. I never designated the zip field in the run options for my table, which worked fine since the other fields were able to make the match.

One other problem I had: I was using a table copied out of a shapefile, rather than a straight database, so the FIDs were still included a few times when I imported the table and forgot to delete them. The geocoding wouldn't run unless the name for the FID field was changed slightly. (This was the problem at the time of my March 6 post).

Shawn, I don't know if any of the above will help you (maybe designating more fields would help your success rate?), but I have no idea what's going on with your offsets. Mine worked fine, but it's also not something I'm worried about because I have to hand-adjust the points based on historic data. The only records I could find online related to offsetting problems recommended installing SP2, so you might want to make sure you have that.

[jborgion]

Good catch Katherine. Thanks for the follow up!

[Shawn_Sumpter]

Kathrine:

Thanks for your update. It really helps closing the loop. I was possitive that my updates were current since I was cc'd on a request and confirmation of update. Sighhhhhh. Always check your own machine! Apparently NONE of the version 10 service packs have been installed. Hopefully this will clear up my issues.

Shawn