Geocoding: Multiple Buildings, One Address, has Unit Letters

[AaronRodriquez]

Good Day All,

I've looked around the forums, and maybe I missed the correct thread, but I thought I would ask the Community. Here goes...

I'm working in 9.3 trying to geocode addresses. I'm using the US Street w/ Zones locator style.  The problem is I have 5 addresses, 4 of which match at 100%, while 1 is being difficult.

The addresses are:

#### W Casa Blanca Rd A
#### W Casa Blanca Rd B
#### W Casa Blanca Rd C
#### W Casa Blanca Rd D
#### W Casa Blanca Rd E

The above are typed EXACTLY as they are in both Reference and Address Tables. So while still using the same locator style, all addresses are matched, EXCEPT, the "E" address. I've looked at the spelling of the refrence data layer (Roads file) and compared it to the address and they match perfectly. The Range of the road is fine or the first 4 wouldn't have matched. The fields I'm using for Street Name, Prefix Direction and Suffix are all spelled correctly and nothing has extra spaces before or after the address in either the reference or address layers. 

In Prefix Direction I have "W";
In Street Name I have "Casa Blanca";
In Suffix Type I have "Rd".
Again, no spaces, spelled the same in each address, etc...the only difference is the letter at the end, but each is different and the first four matched.

Now I have seen links here saying to use the single house locator style, but I cannot use this style since it doesn't account for certain aspects that we need to check against (ex address range). However, I'm not too familiar with Address Locators, so Im not sure if this makes a difference in how it matches certain address. But the requirements of our State require that we have ranges and zones.

I guess I'm just wondering if anyone out there has run into issues like this, where it will find all apt #s while not using the correct Locator, but can not find one of the units.

Any help would be GREATLY appreciated. Oh and if you need any other details, please, PLEASE ask. In my head this all sounds correct, but someone out there might not understand what I'm talking about. Ask and I'll try to explain it more clearly.

Take Care,

Aaron R.


UPDATE:  PS. I just talked with my coworker who is working on a different area of the same Community. She has 6 address w/ letter units. 5 of which are matching, while one is not. Here's the addresses and if they match or not:

#### W Airport Ln A - Matched
#### W Airport Ln B - Matched
#### W Airport Ln C - Matched
#### W Airport Ln D - Matched
#### W Airport Ln E - UNMATCHED
#### W Airport Ln F - Matched

Like b4, all are same circumstances.  kind of wondering if the "E" is the problem. Does Arc have a problem with capital E's?

[JoeBorgione · Accepted solution]

I think your problem lies in the fact that E is often considered as a suffix direction and you are getting dinged for not having E in the suffix_direction field in your street data; the locator is looking for it but since it's not there it does not match.

Try this:  try to geocode that address without the E on end of it.  My guess is you'll get a partial match on all the streets including the problem child.

[AaronRodriquez]

Thanks Joe,

I found that you are correct. The address locator was thinking the "E" meant East. I found a work around, but not sure if I should share it here due to its unconventionality(?), but it deals with adding the E to a small segment of the road. Oh and I think I messed up the ranking of your post....I meant to uprank it, but i think my browser messed that up, SO...


FOR ANYONE WHO LOOKS AT THIS POST, JOE WAS CORRECT, SORRY FOR THE DOWNRANK

[ScottCorwin]

It still behaves the same, in different scenarios. In the case i'm dealing with it's EAST LAKE or WEST LAKE.  I had been using the locator to help find data gaps, however, i just discovered that an address coming in a E LAKE matches because it views the E as EAST.  Normally fine, but for my workflow not fine.  What was your work around?