Geocoding with Alternate Names

679
5
09-13-2019 10:39 AM
JoeBorgione
MVP Emeritus

I have created a US Dual Range with Alt Names style address locator and I'm seeing a problem when I try to match with the alternate names. In an earlier post it was explained that the Alt names table needed map the same fields in the alt names table to the  primary table.

The problem I'm having happens when I create the locator in python (pointing to 10.6 or Pro 2.4 arcpy) or when I use the Create Address Locator tool in ArcMap 10.6.

In addition to my address range fields, my primary table (centerlines feature class) has:

PreDir

Name

Type

SufType

My alt names table is identical to the list above. When I enter the address of 93 E Greenwood Ave ( or provide it in a table of addresses) it comes back as such with a 100% match.  However, when 93 E 7500 S is the address, I get dinged 10 points and the returned address is in the form of 93 E 7500 AVE S.  I hope this isn't expected behavior.

This happens when I interactively use the Locate Tool in Pro, the find address tool in 10.6 or when geocode a table.

 

I tried calculating the SufType field in my alt names table to <Null> but the same problem persists.

How do I convince the locator to drop the SufType and give me the 100% match I should be getting?

Shana Britt

Eric Anderson

Edited to add:  I also used the ArcGIS Pro 2.4 Create Locator tool and got the same sort if return but the score is better:

That should just about do it....
0 Kudos
5 Replies
JoeBorgione
MVP Emeritus

Here is the solution, at least when using Create Locator in ArcGIS Pro 2.4:

I create the altnames table with the fields as indicated above. In order to get rid of the POSTTYPE values, all I had to do is calculate the all the values to None (<Null>)....  Haven't tested this with CreateAddressLocator though since I'm working with CreateLocator only at this time.

Shana Britt

Eric Anderson

That should just about do it....
0 Kudos
MichaelVolz
Esteemed Contributor

Can you please explain the section "I create the altnames table with the fields as indicated above. In order to get rid of the POSTTYPE values, all I had to do is calculate the all the values to None (<Null>)...." as I don't quite follow what you are saying and I can see using this functionality in the not too distant future?

0 Kudos
JoeBorgione
MVP Emeritus

Sure Michael-

Here in Salt Lake County we have two types of streets: Alpha names and Numeric names:

S STATE ST

E 1100 S

In the primary centerlines feature layer:

Alpha names have a prefix direction, name, and type

Numeric names have a prefix direction, numeric name, suffix direction

All streets have Left-From, Left-To, Right-From, Right-To address range fields. The centerlines has a JoinID field, and all the Alpha named streets have a unique value in the JoinID field.  Numeric named streets have a null JoinID value.

Every alpha named street also has an alternate numeric name along with an alternate suffix direction.

S STATE ST has an alternate numeric name of 100 and and an alternate suffix direction of E and those two fields are maintained in primary feature layer:

4555 S STATE ST is the same address as 4555 S 100 E.

With the primary feature layer carrying all the data I need to geocode, it's easy for me to have a stand alone alt names table in a geodatabase, that has :

JoinID

PreDir

AltNumericName

AltSuffixDir

Type

When ever I create a new locator, I first truncate the alt names table, and append in the records it needs to contain.

It's that type field that was causing me problems.  The field needs to be there, but by calculating the Type field values in the alt names table to <Null> I avoid the mojo described in the original post.

Drop me an email and we can continue this if need be.

That should just about do it....
0 Kudos
MichaelVolz
Esteemed Contributor

So in your case, which is data specific, your ALT NAME Table has no records with Type field set to anything but Null?  If that is the case, my data is different from yours and I might not need to apply your workaround.

0 Kudos
JoeBorgione
MVP Emeritus

So in your case, which is data specific, your ALT NAME Table has no records with Type field set to anything but Null?  Yes. that is correct.  You'll need to develop an alt names table and the respective values to suit your needs; geocoding in and of itself is data specific...

That should just about do it....
0 Kudos