Locators should return primary route names when an alias is used in the search

[DanielBorden]

I work in public safety.  In this profession, one of the biggest deficiencies in ESRI locator technology is that the locators do not offer access to the ACTUAL route name if an alias was used to find it. 

Public safety uses aliasing of route names in ways most users may not, as the focus is minimizing keystrokes, not simply supporting altername names for routes.  For example, a route's primary name may be "MARTIN LUTHER KING JR BLVD" but the user uses an alias keyin of "MLK."  The alias, if provided as an alternate name table entry, works fine, but the only locator returns offered will use "MLK," which is NOT the actual route name.  Reporting, legal documentation, etc., need the actual route name.

Ideally, the actual route name would be the primary return, and the alias provided as an additional, alternate return.

[ScottFedak2085]

Our PSAP has ran into this issue as well. Aliases are needed to support robust searches but need to default back to the authoritative address for data consistency and record keeping purposes. Building this enhancement into locators would also provide benefits to workflows unrelated to public safety as well. I see two things needed for this:

• When an alias is utilized, 'official' and 'Alias' output fields should be provided. This would provide developers more flexibility in how a locator is utilized.
• Provide a checkbox in the locator properties that determines if a locator response defaults to the authoritative data or the alias

[ShanaBritt]

@DanielBorden @ScottFedak2085 ,

Since ArcGIS Pro 2.6 there has been the ability to specify which street name is returned either the name from the primary data or the matched name, which could come from the alternate name table using the Preferred Street Name property 

If the reference data is normalized and the primary table does not contain street name values, but the alternate name table does, the Primary Name Indicator field can be mapped to a field in the alternate name table that contains a value indicating whether the record is the primary name. The Street Name role field must be mapped because it and the Primary Name Indicator value are used to define the Preferred Street Name that is returned when geocoding. If this field is not mapped, the first record in the alternate name table will be used as the primary value. An illustration of the Primary Name Indicator in an alternate name table can be found at the bottom of the following topic https://pro.arcgis.com/en/pro-app/latest/help/data/geocoding/fundamentals-of-alternate-name-tables.h....

At ArcGIS Pro 3.1 similar functionality was added for when you have duplicate features in the primary reference data for the alternate street names and you want to specify which street name is the primary name, the reference data must have a field that contains a flag that indicates which street name is going to be the primary name returned when geocoding. This field must be mapped to the Primary Street Name Indicator field from the locator role, such as PrimaryStreetFlag. If the Feature ID is mapped, the Primary Street Name Indicator field is used to define Preferred Street Name of features with the same Feature ID. If the Feature ID is not mapped, each street name from the primary reference data is marked as Primary because de-duplication will not work and each street name is stored independently. (https://pro.arcgis.com/en/pro-app/latest/help/data/geocoding/collapse-duplicate-features-in-the-data...)

If you build the Atlanta locator with the alternate name table from the Create Locator tutorial  you can test the Preferred Street Name settings using the address '30 Atlanta Blvd, Atlanta, 30309', where "Atlanta Blvd" is the alternate name and the street name from the primary data is "Old 10th St".

Please let us know if these settings do not meet your needs.

-Shana

[ScottFedak2085]

@ShanaBritt and @DanielBorden. I built a quick Street Address Role locator and linked it to an alias table and what Shana described worked. After building the locator, I set the Preferred street name to Primary street name 

When I searched for an alias name, the name in the StreetAddress primary table was provided as a suggestion instead of the alias. I'm failing to think of a use case here, but providing some output fields indicating that an alias was utilized or that an alias name exists could be useful to exploit in some applications. I have not come across any output details that indicate that this alias relationship was utilized.

Shana, do you have anything that offers models on how to build aliases? I often get this error when building locators with aliases:

WARNING 003106: The 'Street Address' dataset has a unique ID field mapped to the 'Street Join ID' role field. This join strategy is not optimal and may lead to degradation in performance and increased locator size.

I'm not building country or world wide locators, so this isn't really an issue, but my current alias model utilizes a unique Road Centerline (RCL) segment ID for each feature. This unique ID is a foreign key that links to a record in the alias table if one or more aliases for that segment exists. This allows me to not only tie multiple alias names to a street segment, but also isn't a blanket street name join like Main Street = State Highway 100 which would erroneously specify segments with an alias that it does not have.

[ShanaBritt]

@ScottFedak2085 , The help topic for the 003106 warning you are getting describes what is going on, but the best option to optimize the locator performance and size is to have a Many-to-One or Many-to-Many relationship between the primary StreetName  and the alternate street name table using a StreetNameID in both tables. The same principle would apply to alternate city names, neighborhood, or county names (Los Angeles County vs Los Angeles) or any of the other supported alternate name table roles.

Here is an illustration of what I'm describing.

-Shana

[ScottFedak2085]

@ShanaBritt Thank you for the information. I'll just have to build in an "AliasJoin_ID" type field to build that many to many relationship if I notice performance issues. Since we already have the relationships built, it wouldn't be very hard.

I would maybe suggest that ESRI re-work their documentation to mention using or building an "AliasJoin_ID" type field instead of utilizing a "StreetNameID". I at least find the use of "StreetNameID" in the documentation to be confusing as this is usually a link to a table inventorying a table of unique street names. We have StreetNameIDs in our data, but it couldn't be utilized as the join field because not every road segment with a given name will necessarily have an alias. For instance, you can have a state highway that only goes down part of Main St and than routes down Martin Luther Kind Drive.

Thanks again for the help!

[ShanaBritt]

@ScottFedak2085 I just randomly selected the name "StreetNameID" in the explanation to you. The field could be named anything. Each role in the Create Locator tool has a Join ID field used to link to an alternate name table or to another role, like PointAddress and Parcel. These role fields are described in https://pro.arcgis.com/en/pro-app/latest/help/data/geocoding/locator-role-fields.htm. You can still build the locator with the alternate street name table using your current workflow and continue to get the warning, and the alternate name an preferred street name will continue to work.

Glad I could help.

-Shana

[ScottFedak2085]

@ShanaBritt Thank you for all the information and for being so active in the forums. I see your name on many of the locator orientated questions, and you are always timely and thorough in your responses.

Thanks again!

[ShanaBritt]

Thanks @ScottFedak2085 , I really appreciate feedback. 😊

[DanielBorden]

The other issue being overlooked here is that the best solution is to provide BOTH values, either as separate returns, or with the searched term as part an existing return (such as long_label).  In public safety, meticulous recordkeeping is king!