Geocoding Addresses with Apartment Units

Greene_Chris · ‎04-18-2011

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

BillRose · ‎04-09-2012

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?

BillRose · ‎04-18-2012

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?

RoyJackson1 · ‎06-20-2012

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

DanMcCoy · ‎07-29-2015

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

DanMcCoy · ‎12-09-2015

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

BillRose · ‎06-20-2012

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

jeffduncan · ‎08-09-2012

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

esri give a hang about it?

NickTaylor1 · ‎10-23-2012

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

BrianOevermann · ‎10-23-2012

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

HXiao · ‎11-13-2012

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.