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; } } }

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

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

DanMcCoy

sacdou wrote:
Has anyone resolved this issue or know if it's been resolved at 10.3?

This works with the out-of-the-box locator in 10.3.1

Dan

DanMcCoy

Roy Jackson:

When you pass in an address without a unit designator to the get candidates method, addresses having a unit are ranked the same as an exact match without a unit. This effectively means that the geocoding operation does not perform correctly for any location having secondary addresses (has units) AND a primary address (no units), such as an apartment building with a office at the primary address.

Has anyone resolved this issue or know if it's been resolved at 10.3?

Thanks,

Dan

dewright_ca

Annie, I know this is not the kind of response you would like. But ESRI is planning to have a Sub-Unit capable Geocoder available at 10.3; I had the opportunity to meet with them at the UC and they are making a serious effort to have this functionality in place.

AnnieSitu1

Hi Brad,

I am running 10.2.1, the locator doesn't seem to work. Do you have a chance to work on and provide us a newer version? Your help is very much appreciated.

DanMcCoy

Please vote to include (and support)unit locator styles in the core product.
http://ideas.arcgis.com/ideaView?id=08730000000by67

KimOllivier

Hi Brad,

When you pass in an address without a unit designator to the get candidates method, addresses having a unit are ranked the same as an exact match without a unit. This effectively means that the geocoding operation does not perform correctly for any location having secondary addresses (has units) AND a primary address (no units), such as an apartment building with a office at the primary address.

Roy

Earlier in the forum this is exactly what was asked for. You can't please everyone all of the time. I would like this behaviour too, so I am fiddling with the configuration file to change it.

BradNiemand

Attached is a locator style that might help with the issues you are seeing with Standardization.

Brad

USStandards.lot.zip

BrianOevermann

Sandra,

If you are using the version that Brad has posted, the "B" in 123B Main St would need to be part of the house number field. [Correct me if I am wrong about that, Brad]

For the version I posted, here is a bit of context...

Our City is part of a regional alliance that happens to have a long-standing address layer schema standard for use in certain regional applications. The schema has its shortcomings and many cities maintain their address layers with fields that meet their individual needs but can still be exported to that regional schema for data sharing.

We have some legacy addressing that includes fractional halves (i.e. 123 1/2 Main St) as well as your example of 123B Main St. While the "B" is really a unit indicator, these legacy addresses have used the 123B format for so long that we simply treat them as fractionals. But we are a reasonably small city and the number of these is small. All newer addressing adheres to the 123 Main St Unit B format.

The regional schema mentioned above is a numeric field, so that prevents me from concatenating the fractional half or letter into the house number. Thus, my version of the locator includes a fractional field as well as the unit field.

For those legacy addresses, the "B" goes into the fractional field and not the unit field. In the locator, a space is required between the 123 and the "B". Otherwise the 123B will be searched against the house number only instead of the house number and fractional fields.

All of that said, if you standardize your "A" and "B" units as 123A and 123B, you are likely better off either making them a part of the house number or using the fractional field rather than the unit field. You really need to proceed based on how you expect users to enter the address for matching, and there is no right answer.

Maybe others have some additional ideas. Apologies for the length but I wanted to provide some context regarding why my version is built the way it is. Admittedly, my primary intent was to create something that worked for us. The fact that others might be able to utilize it was simply a bonus.

I do hope that ESRI begins to provide these locators in the "base code".

SandraLuken

The locator xml provided has been very useful, but seems to require the addresses to be entered as '123 Main St. B' or '123 Main St 9' (where 9 in this example represents the unit number). What needs to be done to the xml to allow users to enter as a single line address '123B Main St'?

ArcGIS 10.0 SP5

Sandra

ChadTQuinn

Is there a Locator with Unit .loc tool for 10.1 SP1?

NickTaylor1

Prectaylor,

Are you using the style that Brad has posted or the one I have posted? Are you on 10.1 or an earlier version? And the way I read your post, the only issue is with the 'NE' directional? Extremely odd...

Maybe Brad (or others) have some insight. I can successfully use all directionals--in 10.0 as well as 10.1.

There isn't an extra space in your prefix data field for the 'NE' by chance? (i.e. ' NE' instead of 'NE' )

Brian

I am using 10.1. I have used both of the styles without a great deal of success. There are no strange spaces and I have even tried to have it look at only the direction. I am going to try to dig into the xml and will update with any new information. Thanks all for your help.

HXiao

Hi Brad,

I have been doing a ton of testing, using addresses across the nation with your updated locator, and have a couple issues to report.

Using your locator with the standardize addresses tool, all street names with two words, and no street type or suffix directional or unit type / num, are parsed incorrectly. The second word in the street name gets placed into the ADDR_UN field. For example, try to run standardize addresses with "100 RACING WINDS". WINDS gets parsed to UN. There are lots of streets and addresses under this scenario. This in turn is messing up results for geocoding / get address candidates. So, if you have 100 RACING WINDS in your data, you use your locator, and run geocode to find the same address, it doesnt match. However, 100 RACING # WINDS will match.

When you pass in an address without a unit designator to the get candidates method, addresses having a unit are ranked the same as an exact match without a unit. This effectively means that the geocoding operation does not perform correctly for any location having secondary addresses (has units) AND a primary address (no units), such as an apartment building with a office at the primary address.

As a result of these issues, my code has to look at an address, determine if there is a secondary using our own parser, then based on presence / absence of secondary either use your locator with every address in my data, or the US Address (no units) locator with ONLY the addresses in my data that lack unit type and num - very clunky and not possible for most other users.

Who do you recommend that I contact at esri to work through these issues? Are you actively updating this locator?

I would be happy to provide additional documentation / screenshots of the discrepancy patterns.

Thank you,

Roy

We're experiencing the same problem as Roy described.

Strangely, for addresses have only house number, street name, and street type, some of them are parsed correctly, but some not. A lot of the incorrectly parsed addresses have street names which could be a street type and indeed are in suf_type in grammar section of the style file. For example, "234 front st" cannot be parsed correctly, with "front" being placed in street type, "s" in unit type, and "t" in unit number. "300 mission rd" cannot be parsed correctly, with "mission" placed in street type, "rd" in unit number. With this incorrect parsing, the match scores are very low. At the other side, "2400 Liberty Dr" is parsed correctly as "Liberty" is not in suf_type in grammar section. So a test was performed to see whether taking out a specific suf_type (e.g. taking out "front" and "mission") would resolve this problem. There was no luck.

The technical paper "customized arcgis 10 locators" is really not enough. ESRI, please help.

BrianOevermann

Prectaylor,

Are you using the style that Brad has posted or the one I have posted? Are you on 10.1 or an earlier version? And the way I read your post, the only issue is with the 'NE' directional? Extremely odd...

Maybe Brad (or others) have some insight. I can successfully use all directionals--in 10.0 as well as 10.1.

There isn't an extra space in your prefix data field for the 'NE' by chance? (i.e. ' NE' instead of 'NE' )

Brian

NickTaylor1

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

Thanks so much for posting this parsing script. I am new to parsing using GIS but have written a few scripts in other programs. When I tried to apply this script it seems to misinterpret the "NE" street direction indicator. It leaves the ADDR_PT field blank but uses "Sthy" in the ADDR_PT field. I have tried to look through the code but am thoroughly lost. The script works great for all other directions. Any help would be greatly appreciated. See input and output below. Thanks!

Input Address: "740 NE 23RD AVE APT B24"
Output fields:
ADDR_HN: 740
ADDR_PD: Blank
ADDR_PT: Sthy
ADDR_SN: 23RD
ADDR_ST: Ave
ADDR_SD: Blank
ADDR_UT: APT
ADDR_UN: B24

jeffduncan

Just want to add support for this post.... I recently used the standardize addresses tool and observed the same issues Roy describes. I also see that ESRI has not included a "building unit" locator style in the new features for 10.1. This really is needed.

yes I'm getting this behavior too:

When you pass in an address without a unit designator to the get candidates method, addresses having a unit are ranked the same as an exact match without a unit. This effectively means that the geocoding operation does not perform correctly for any location having secondary addresses (has units) AND a primary address (no units), such as an apartment building with a office at the primary address.

is there anybody who solved the above problem? it must be pretty xyz common

esri give a hang about it?

BillRose

Just want to add support for this post.... I recently used the standardize addresses tool and observed the same issues Roy describes. I also see that ESRI has not included a "building unit" locator style in the new features for 10.1. This really is needed.

Hi Brad,

I have been doing a ton of testing, using addresses across the nation with your updated locator, and have a couple issues to report.

Using your locator with the standardize addresses tool, all street names with two words, and no street type or suffix directional or unit type / num, are parsed incorrectly. The second word in the street name gets placed into the ADDR_UN field. For example, try to run standardize addresses with "100 RACING WINDS". WINDS gets parsed to UN. There are lots of streets and addresses under this scenario. This in turn is messing up results for geocoding / get address candidates. So, if you have 100 RACING WINDS in your data, you use your locator, and run geocode to find the same address, it doesnt match. However, 100 RACING # WINDS will match.

When you pass in an address without a unit designator to the get candidates method, addresses having a unit are ranked the same as an exact match without a unit. This effectively means that the geocoding operation does not perform correctly for any location having secondary addresses (has units) AND a primary address (no units), such as an apartment building with a office at the primary address.

As a result of these issues, my code has to look at an address, determine if there is a secondary using our own parser, then based on presence / absence of secondary either use your locator with every address in my data, or the US Address (no units) locator with ONLY the addresses in my data that lack unit type and num - very clunky and not possible for most other users.

Who do you recommend that I contact at esri to work through these issues? Are you actively updating this locator?

I would be happy to provide additional documentation / screenshots of the discrepancy patterns.

Thank you,

Roy

RoyJackson1

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

Hi Brad,

I have been doing a ton of testing, using addresses across the nation with your updated locator, and have a couple issues to report.

Using your locator with the standardize addresses tool, all street names with two words, and no street type or suffix directional or unit type / num, are parsed incorrectly. The second word in the street name gets placed into the ADDR_UN field. For example, try to run standardize addresses with "100 RACING WINDS". WINDS gets parsed to UN. There are lots of streets and addresses under this scenario. This in turn is messing up results for geocoding / get address candidates. So, if you have 100 RACING WINDS in your data, you use your locator, and run geocode to find the same address, it doesnt match. However, 100 RACING # WINDS will match.

When you pass in an address without a unit designator to the get candidates method, addresses having a unit are ranked the same as an exact match without a unit. This effectively means that the geocoding operation does not perform correctly for any location having secondary addresses (has units) AND a primary address (no units), such as an apartment building with a office at the primary address.

As a result of these issues, my code has to look at an address, determine if there is a secondary using our own parser, then based on presence / absence of secondary either use your locator with every address in my data, or the US Address (no units) locator with ONLY the addresses in my data that lack unit type and num - very clunky and not possible for most other users.

Who do you recommend that I contact at esri to work through these issues? Are you actively updating this locator?

I would be happy to provide additional documentation / screenshots of the discrepancy patterns.

Thank you,

Roy

BillRose

To follow up on my last post, we've solved some problems by moving our unusual building number suffixes into the unit field. But we're still seeing issues with both of the locators posted here. Most puzzling is why a very simple address like '5998 Someplace Ave' sometimes fails to match. These addresses have always matched with the standard out-of-the-box locator styles. Could it be that the absence of a building number suffix and/or unit is lowering their score?

BillRose

I've spent some time with the latest versions of the two locators posted here Brad's "USSingleHouseUnits.lot" (post #44) and Brian's "USAddressWithUnit.lot" (post #35). Is it possible to combine these by adding the fractional address field to Brad's locator?

Also, we happen to have addresses that use both fractions and values such as "B" and "1001" in the building number suffix field. So all of the following are valid: "1200 1001 W Main St", "1200 1/2 W Main St", and "1200 B W Main St Apt 2."

Neither of the posted locators seems to handle all three of the above formats. Can this be accommodated?

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 "xyz" in the field so you don't want that in the locator.

Brad

KadeSmith

Just out of curiousity, what was the issue?

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.

USSingleHouseUnits.lot.zip

KadeSmith

SampleDataEsri is the values I'm trying to geocode.

SubAddressForLocator is the shapefile for creating the locator.

SampleData.7z.zip

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

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

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

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.

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 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

dewright_ca

Brad,

Thank you for the latest style sample. It definitely filled in the gaps that the customization white paper fails to cover. My functional style file is attached. It honors fractional address fields as well as separate unit type and unit number fields. I hope folks find it useful if their data is structured in a similar way! Share it far and wide and please, ESRI, polish it and include it as a default in 10.1! I never want to have the need to do this customization again!

You need to place this style file in the locator directory of your ArcGIS install. The default location is:
C:\Program Files\ArcGIS\Desktop10.0\Locators

Our site address data layer uses the following fields:
Address
Address Fractional (i.e. the "A" or "1/2" in "80 A Main St" or "80 1/2 Main St")
Prefix Direction
Street Name
Street Type
Suffix Direction
Unit Type (i.e. Unit, Ste, #)
Unit Number
City
ZIP Code
State

The style has not been tested in any other configurations.

EDIT: We are currently on SP1--no testing with SP2 has been done!

Enjoy,
Brian

Brian; is the County Assessor building addresses with Fractional's? Or is that being assumed by the City as correct? We are dealing with addressing in the county there and are finding that the fractionals are failing with USPS address standardizing; since that is not a general accepted value.

Thoughts?

BradNiemand

You are correct. This is your style.

Brad

USAddressWithUnit.lot.zip

BrianOevermann

Brad,

I am not seeing the fractional field in your edit of my style. Is it possible that you attached your version of the style to the post instead?

BradNiemand

It should work but I have not tested it in 10.0 SP1 so I am not 100% sure. If you have an issue though, let me know and I can take a closer look.

Brad

BrianOevermann

Thanks, Brad. I had guessed that the explanation would not be short and sweet--geocoding styles don't really lend themselves to nice, short explanations.

Final question: Does the latest fix require v10 SP2 to work properly or will it function in v10 SP1 as well? We are still rolling over to SP2 so I want to be aware of any "gotchas".

Thanks again for your time in answering questions/tweaking styles. I know you are a busy person.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

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