nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Order of aliases is important

PeterHanmore

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

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

BradNiemand

If you are editing the already created locator file (*.loc.xml file) then what you are saying is correct. If you edit the locator style template (USAddress.lot.xml in the ArcGIS Install directory in the locators folder), then create the locator from scratch again, it can be the first, second, ... or even last entry in the alias definition.

Brad

PeterHanmore

it can be the first, second, ... or even last entry in the alias definition.

If that's the case (order does not matter in the template) how does it know what order to put them in when you create a locator? Since, from my testing, the city stored with the spatial record has to come first, how does the locator know which city in an unordered list of aliases has to come first?
Or, is it up to the developer to ensure that the first name in a group of aliases is the primary name and then all OTHER aliases can be in any order?

Peter.

BradNiemand

It really doesn't matter the order of the aliases because they are all treated as equivalent but the first alias in the list is treated as the primary.

Brad

PeterHanmore

It really doesn't matter the order of the aliases because they are all treated as equivalent but the first alias in the list is treated as the primary.

Brad

Sorry Brad, but I'm finding your answer a bit contradictory....
If the order doesn't matter because they are all equal, then there really isn't (shouldn't be) a need for a 'Primary' city name.
A primary name would only be a necessity if other names had a relationship to it (ie. they are alternates for the first name, but not alternates for other names in the list).

So... for clarity, which of these statements is the correct one:

1) when someone adds a new set of aliases to the template, they MUST put the primary name first followed by any aliases in random order? This will result in any of the 2-n aliases being equivalent to the first name but not other non-primary aliases.
Ex. New York, Queens, Brooklyn, Manhatten are in a list of aliases; The primary name is New York but can also be called Queens, Brooklyn or Manhatten, but Queens is not an alias for Brooklyn or Manhatten (and vice versa).

2) when someone adds a new set of aliases to the template, the order has no relevance and all names in the list are all aliases for each other.
Ex. same alias list as above. New York can be called Queens, Brooklyn or Manhatten AND Queens can also be called Brooklyn or Manhatten.

3) same statements as above except Queens could also be called New York (reversing the order - primary name is also an alias for alternate name)

OR.... am I missing your intent completely. Just looking for clarity.

Peter.

BradNiemand

Peter,

Statement #3 is correct. All aliases will be treated as if they are exactly the same.

Brad

PeterHanmore

Peter,

Statement #3 is correct. All aliases will be treated as if they are exactly the same.

Brad

I meant to edit my post but you answered before I could 🙂
#3 should have read: Same as #1 AND Queens, Brooklyn and Manhatten can all be called New York
#4 should be: Same as #2 AND order not at all important - New York or Queens or Brooklyn or Manhatten could have been the primary name. Every name is equal to every other name and has no bearing on how a city is found in the index.

I'll say that #4 does NOT work as it represents our initial understanding of aliases which is disproven by my tests shown in the original post.

BradNiemand

Peter,

After you updated with this latest post, statement #4 is now the correct one. When you said you experience it not working in an earlier post, I mentioned that aliases really should be added to the lot.xml file and then the locator should be re-created. This, and only this, will allow for the aliases to work as described in #4.

Brad

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.