Geocoding Addresses with Apartment Units

[Greene_Chris]

Hi all -

It's been a tedious slog with address locators in 10 so far. Now that the zip code/city/state issues has been resolved with sp1, we are now trying to tackle the addresses with units. 

It seems that the USAddress - Single House locator best fits our needs. I have been setting the Additional Field to our unit field yet when looking at the geocoding results it's obvious that the locator is not seeing this additional field value as an apartment unit. For example, when using the find tool to locate 115 Brown St A, nothing found. However, a search for 115 Brown St will return two options, neither one containing the additional unit information. Has anyone else come across this and found a work around?

As a side note, to get around the zip code issue, I did load in the 931 locators which worked great until I needed to assign privileges to other user groups.

Thanks in advance-

Chris

[SargentMcDonald]

I have attached a Briano's style with some updates.  The only difference between the style that I posted before and the style that I am attaching now is that it contains an extra field for the fractional house number.  Other than that, I have just included some of the fixes that I found and that will correct the "w vs west" issue.

Brad

Thanks for fixing the W vs West issue. Unfortunately I have a few other oddities going on in my testing I was hoping to go through with you. I have added a few of our city specific aliases to the xml with mixed results. Most work fine. Here are a few that don't.

Primary: N I70 frontage rd
Alias: W 48th Ave
Won't find any results for W 48th ave

Primary: W 58th Ave
Alias: W 58th Ave Frontage Rd
Score of 19% when using Frontage Rd . Same situation on W 72nd Ave but when using W 72nd Frontage Rd score comes back as 92%. Don't have either example added to xml as site specific aliases.


Primary Name: Ralston Rd
Alias: W 58th Ave  and W 64th Ave
This one is tough. County Addresses use both Ralston and W 58th as primary but this locator won't find alias results for Ralston Rd. Only finds alias when address has W 58th Ave (or 64th Ave) as the alias and Ralston as primary. This one is confusing to explain since Ralston runs diagonal across the city and aliases 2 different numbered streets. Seems weird that it works one way but not the other.

Alias code below:

<alias_def>
             <alt>ralston rd</alt>
             <alt>w 58th ave</alt>
<alt>w 64th ave</alt>
          </alias_def>
       <alias_def>
       <alt>n I 70 frontage rd</alt>
  <alt>w 48th ave</alt>
          </alias_def>

Thanks for any insight or assistance.
Sargent

[BrianOevermann]

Sargent,

I am going to defer your questions to Brad (or other knowledgeable folk).  We are not yet using alias tables so I have no way to test.

Question for Brad:  I may butcher this due to my limited knowledge regarding aliases tables, but what is the difference between creating an alternate name/alias table joined via a join ID and adding code to the style like Sargent has?  Is one method preferred over the other?  Or am I confusing two different concepts/uses?  We are headed in this direction so I would like to fill in the gaps of my knowledge.

Brian

[SargentMcDonald]

I have actually tried this using our alias table and a JoinID with and without the above code modifications to the XML. Same results which adds to my confusion.  I double checked the alternate table was correct for these records also.

[BradNiemand]

I will try to clarify some of the resent questions about place name alias table versus alias tables in the style in a couple quick sentences.

Alias tables in the style should be used for "common abbreviated forms" of words (ie. first, 1st or MLK, Martin Luther King).  Place name alias tables should be used for mapping between two completely different street names (ie. w 58th ave is also ralston rd).

I hope this gives some insight.

Brad

[KadeSmith]

I'm using the lot file from post #21 by brad5993 and getting really random results and am looking for some help if anyone can please explain what's going on.

Here are some sample results:

Table Data to Geocode - Shapefile Points Data
65 S 1ST W APT 104 <> 65 S 1st W 104
160 W 5TH S APT 301 <> 160 W 5th S 301

242 W 6TH S APT 10 = 242 W 6th S 10
136 W 3RD S APT 6 = 136 W 3rd S 6
460 S 2ND W APT 4 = 460 S 2nd W 4
208 S 2ND W APT 1 = 208 S 2nd W 1

The pattern I have noticed is that anytime the apartment number has more than 2 characters, the locator will not match.  How can I make it match on apartments with 3 or more characters?

[BradNiemand]

This should not be the case.  There is no limitation to the number of characters that an apartment number can be.  I can try and take a look at it if you could provide me some sample data and addresses.

Brad

[KadeSmith]

SampleDataEsri is the values I'm trying to geocode.

SubAddressForLocator is the shapefile for creating the locator.

[BradNiemand]

SampleDataEsri is the values I'm trying to geocode.

SubAddressForLocator is the shapefile for creating the locator.

I think I have solved your issues.  I have attached an updated style.

[KadeSmith]

Just out of curiousity, what was the issue?

[BradNiemand]

Just out of curiousity, what was the issue?

It had to do with the way that the reference data was standardized at build time.  Also, when you build the locator, only specify HouseNumber, LabelName for street, and UnitNumber.  Leave all of the other fields to None.  These fields get concatinated before standardization so it doesn't matter if you only have the three fields, it will separate them out for you.  Also, I saw that suffix direction and maybe some other fields had "xxxxxx" in the field so you don't want that in the locator.

Brad