Create Address Locator With Alt Names

[JoeBorgione]

I am trying to create a Dual Range address locator using center lines  with an alternate names table in ArcGIS 10.6.1 as well as ArcGIS Pro 2.4.  Neither of them work for me.  I am successful when I use the Pro 2.4 Create Locator tool and provide the exact same data in the appropriate roles.  

Anyone else have this issue?

Shana Britt‌

[MichaelVolz]

Can you explain in detail why you think the Create Address Locator with Alt Names in not working in ArcMap 10.6.1?

I believe the same type of Address Locator is working for me in 10.7.1, so I'm curious what your address locator settings are.

Do you have Match with no zones set to No as Yes is the default and I know for myself that setting is important to get expected results?

[JoeBorgione]

Michael-  every named street in the our area has a numeric coordinate value, the address 4500 S REDWOOD RD is the primary street name while 4500 S 1700 W is the alt name.  In both Pro and 10.6.1 the primary street name returns a hit while the alt name does not.  I am using 'out of the box' settings with respect to scoring; I'd like to tweak them eventually.  In the 10.6.1 version I have Match with no zones set to Yes.  For the locator created in Pro, I did not alter the setting, and the primary name works just fine in Pro. Opening properties in ArcCatalog on the Pro2.4 locator, I can see the Match with no zones set to No, so I don't know how it returns  valid on 4500 S Redwood Rd.

With both locators I check enable suggestions, but when I add them to Pro, the suggestions box is grayed out for both of them, which seems odd to me.

I can send you the parameters file from both if you like, but I'm not doing anything different than I have in earlier versions (9.x.10.3) hundreds of times.

(I have opened a tech support ticket with ESRI...)

[MichaelVolz]

Joe:

Do you have an Alt Street Name(s) that are not numeric?  My road centerline data does not match your data in terms of Alt Names as I do not have numeric Alt Names and my alphabetic Alt Names appear to be working as expected.

You can send screenshots of your parameters files from both.

[JoeBorgione]

All our alt names are numeric, and the components (Predir, Name, Sufdir) are all parsed out in separate fields.  Here's screen cap of the the primary feature class, CenterlinesLite and the corresponding AltNamesLite for one record.  All I do for the AltNames table is turn off a few fields on the primary fc and export the table records.  It's joined with an item called (of all things) JoinID.  You may notice that JoinID is not indexed in the feature class ( no * ) but that doesn't seem to matter; if I create an index for it, it still does'nt match with the alt name.  I thought I'd just try it in ArcPy, but in the Pro online help, there is no accommodation for one and the 10.6 help isn't much different:

CreateAddressLocator(in_address_locator_style, in_reference_data, in_field_map, out_address_locator,...
{enable_suggestions})

CreateAddressLocator_geocoding (in_address_locator_style, in_reference_data, in_field_map, out_addre...

[ShanaBritt · Accepted solution]

Joe:

Did you map the same fields for the primary and the alternate name table. I see that the alternate name table does not have a field for street type and if the POSTTYPE field is mapped for the primary reference data, the schema between the two do not match up and would cause alternate name matches to not be returned. Add a new POSTTYPE field to the alternate name table and map it when building the locator so the schemas match. Another option is to concatenate the street component fields into a single field in both the centerline and alternate name tables, then build the locator only mapping Street Name.

Locators created with the Create Address Locator tool do not support local suggestions in ArcGIS Pro, the locator would have to get published as a service and added back to Pro in order to get suggestions in the Locate pane.

[JoeBorgione]

Hi Shana-

The Primary street name may or may not have a postType;  Sometimes the primary name is alpha, and when that is the case it will have a postType. (S REDWOOD RD)  However many streets are not alpha, only numeric like my street: S 3305 E  and do not have a postType, nor do they appear in the alt names table.  I don't understand why the alt names table needs to have the postType field when it's not mentioned in the address.  When I read "so the schemas match" , shouldn't the alt names table just be a mirror image of the original primary table?  I'll give it a try though and post my results.

Another option is to concatenate the street component fields into a single field in both the centerline and alternate name tables, then build the locator only mapping Street Name.

For years it's been drilled into my head that geocoding works best with parsed out fields of the components so that's how the data is maintained.  I've submitted some sample data, so I'll email you the support case number directly and if you feel the need, you can look at the data.

Okay Shana- I'll have an extra helping of crow to go along with my humble pie. I mapped the PostType and it works...  Beats me, but here is how I did it with python.  Line 53 is what I editied:

arcpy.env.workspace = r'J:\LocatorTesting\CenterlinesAltNames'
locatorStyle = 'US Address - Dual Ranges'
primaryTable = r'J:\LocatorTesting\CenterlinesAltNames\ToESRI.gdb\CenterlinesLite'
altNames = r'J:\LocatorTesting\CenterlinesAltNames\ToESRI.gdb\AltNamesLite'
outLocator = 'J:\LocatorTesting\CenterlinesAltNames\LocatorByPy'
enableSuggestions = 'ENABLED'
fieldMap = """
    'Primary Table:Feature ID' CenterlinesLite:OBJECTID VISIBLE NONE;
    '*Primary Table:From Left' CenterlinesLite:FROMADDR_L VISIBLE NONE;
    '*Primary Table:To Left' CenterlinesLite:TOADDR_L VISIBLE NONE;
    '*Primary Table:From Right' CenterlinesLite:FROMADDR_R VISIBLE NONE;
    '*Primary Table:To Right' CenterlinesLite:TOADDR_R VISIBLE NONE;
    'Primary Table:Left Parity' <None> VISIBLE NONE;
    'Primary Table:Right Parity' <None> VISIBLE NONE;
    'Primary Table:Full Street Name' <None> VISIBLE NONE;
    'Primary Table:Prefix Direction' CenterlinesLite:PREDIR VISIBLE NONE;
    'Primary Table:Prefix Type' <None> VISIBLE NONE;
    '*Primary Table:Street Name' CenterlinesLite:NAME VISIBLE NONE;
    'Primary Table:Suffix Type' CenterlinesLite:POSTTYPE VISIBLE NONE;
    'Primary Table:Suffix Direction' CenterlinesLite:POSTDIR VISIBLE NONE;
    'Primary Table:Left City or Place' <None> VISIBLE NONE;
    'Primary Table:Right City or Place' <None> VISIBLE NONE;
    'Primary Table:Left County' <None> VISIBLE NONE;
    'Primary Table:Right County' <None> VISIBLE NONE;
    'Primary Table:Left State' <None> VISIBLE NONE;
    'Primary Table:Right State' <None> VISIBLE NONE;
    'Primary Table:Left State Abbreviation' <None> VISIBLE NONE;
    'Primary Table:Right State Abbreviation' <None> VISIBLE NONE;
    'Primary Table:Left ZIP Code' <None> VISIBLE NONE;
    'Primary Table:Right ZIP Code' <None> VISIBLE NONE;
    'Primary Table:Country Code' <None> VISIBLE NONE;
    'Primary Table:3-Digit Language Code' <None> VISIBLE NONE;
    'Primary Table:2-Digit Language Code' <None> VISIBLE NONE;
    'Primary Table:Admin Language Code' <None> VISIBLE NONE;
    'Primary Table:Left Block ID' <None> VISIBLE NONE;
    'Primary Table:Right Block ID' <None> VISIBLE NONE;
    'Primary Table:Left Street ID' <None> VISIBLE NONE;
    'Primary Table:Right Street ID' <None> VISIBLE NONE;
    'Primary Table:Street Rank' <None> VISIBLE NONE;
    'Primary Table:Min X value for extent' <None> VISIBLE NONE;
    'Primary Table:Max X value for extent' <None> VISIBLE NONE;
    'Primary Table:Min Y value for extent' <None> VISIBLE NONE;
    'Primary Table:Max Y value for extent' <None> VISIBLE NONE;
    'Primary Table:Left Additional Field' <None> VISIBLE NONE;
    'Primary Table:Right Additional Field' <None> VISIBLE NONE;
    '*Primary Table:Altname JoinID' CenterlinesLite:JOINID VISIBLE NONE;
    'Primary Table:City Altname JoinID' <None> VISIBLE NONE;
    '*Alternate Name Table:JoinID' AltNamesLite:JOINID VISIBLE NONE;
    'Alternate Name Table:Full Street Name' <None> VISIBLE NONE;
    'Alternate Name Table:Prefix Direction' AltNamesLite:PREDIR VISIBLE NONE;
    'Alternate Name Table:Prefix Type' <None> VISIBLE NONE;
    'Alternate Name Table:Street Name' AltNamesLite:AN_NAME VISIBLE NONE;
    'Alternate Name Table:Suffix Type' AltNamesLite:POSTTYPE VISIBLE NONE;
    'Alternate Name Table:Suffix Direction' AltNamesLite:AN_POSTDIR VISIBLE NONE
    """
arcpy.CreateAddressLocator_geocoding(locatorStyle,"{} 'Primary Table';{} 'Alternate Name Table'".format(primaryTable,altNames),
                           fieldMap,outLocator,)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[ShanaBritt]

Joe:

It was true in the past, pre 10.x, that it was necessary to parse the street name into individual fields in the reference data before building the locator with the Create Address Locator tool, but that is not the case anymore as during the build process the street name is getting parsed into the individual components and stored in the index as parsed.

A join occurs between the primary feature class and alternate name table and the number of fields need to match is what I mean by the schema. In your case the primary table had 5 fields and the alternate name table had 4 fields and the number of fields should match between the two.

[JoeBorgione]

That's  great to know.  Thanks so much for the explanation!

[MichaelVolz]

Just out of curiosity.  Were you able to get an Alt Name locator to work in an older version of ArcMap where the schema of the feature class was different than the schema of the Alt Name table?