phanmore

Order of aliases is important

Discussion created by phanmore on Jan 22, 2014
Latest reply on Feb 3, 2014 by bniemand-esristaff
Maybe this is old news to some people, but while trying to sort out some city alias name issues I ran across some unexpected behaviour in our single house locator (parcel data).
From what I've read in the very limited documentation available, the alias lists are simple sets of equivalent names for an object (whether it's a street, state, city, etc.).  I have not seen any documentation that states there should be a specific order for the aliases you create.
However, from my testing, it appears that the FIRST alias in the set (for city aliases at least) must be the name that will be found in your dataset.  Is this common knowledge and I've just missed seeing it in the documentation?  I have tested this with several different cities / aliases and the behaviour is 100% repeatable.  For example:  the dataset contains an address 1417 Hazelwood Dr., Gorham and it geocodes correctly using this address.  However, Gorham could also be called Thunder Bay, so we create an alias for it like so:
<alias_def>
  <alt>THUNDER BAY</alt>
  <alt>GORHAM</alt>
</alias_def>
.... and we would expect the address 1417 Hazelwood Dr., Thunder Bay to now geocode correctly - but it still doesn't match.  If we reverse the order of the two aliases, putting GORHAM first and THUNDER BAY second, then both variations of the address will geocode successfully.

Just wondering if this is known/expected behaviour or have others run into the same issue?  I didn't find anything related to the order of aliases when I searched the forum.

Peter

Outcomes