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:
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?
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:
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.
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?
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 :
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.
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.
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...