Inconsistent Components Use in Worldwide Templates

[msgem]

Hi,

I have observed inconsistencies in the worldwide.yaml templates and their use of components.yaml words. Using generic4 as an example:

generic4: &generic4 |
        {{{attention}}}
        {{{house}}}
        {{{house_number}}} {{{road}}}
        {{#first}} {{{village}}} || {{{hamlet}}} {{/first}}
        {{#first}} {{{city}}} || {{{town}}} || {{{state_district}}} || {{{suburb}}} || {{{municipality}}} || {{{county}}} {{/first}}, {{#first}} {{{state_code}}} || {{{state}}} {{/first}} {{{postcode}}}
        {{{country}}}

One of the aliases for house is building, however the template doesn't recognize that.

This means

house_number: 301
house: Visitor Center
road: Hamilton Avenue
neighbourhood: Crescent Park
city: Palo Alto
postcode: 94303
county: Santa Clara County
state: California
country: United States of America
country_code: US

returns

Visitor Center
301 Hamilton Avenue
Palo Alto, CA 94303
United States of America

However, switching out the house key for building:

house_number: 301
building: Visitor Center
road: Hamilton Avenue
neighbourhood: Crescent Park
city: Palo Alto
postcode: 94303
county: Santa Clara County
state: California
country: United States of America
country_code: US

returns an address without the corresponding house/building value.

301 Hamilton Avenue
Palo Alto, CA 94303
United States of America

Given that these are indeed aliases and therefore should be interchangeable, one could speculate that the template itself is lacking because it doesn't account for all of the possible aliases. Realistically, requiring a template to consider all aliases is overly verbose and doesn't make sense, but many templates' current use of default words versus their alias equivalents is inconsistent and leads to the behavior outlined above.

I also see templates that account for some alias variations, but not all of them. In generic9, suburb and city_district are both present; both of these are aliases to neighbourhood, which is not included.

generic9: &generic9 |
        {{{attention}}}
        {{{house}}}
        {{{road}}} {{{house_number}}}
        {{#first}} {{{suburb}}} || {{{city_district}}} || {{{state_district}}} {{/first}}
        {{{postcode}}} {{#first}} {{{city}}} || {{{town}}} || {{{village}}} || {{{hamlet}}} || {{{state}}} {{/first}}
        {{{country}}}

Possible Solutions

I would like to propose a couple of options:

1. The templates could be reworked to only consider the default word and not any of the aliases. This means the end-users (ie. programming language specific libraries) are responsible for mapping the aliases to their default equivalent before passing the components along to the revised templates.
2. However, if there's a reason why the templates were designed the way they are and should not be modified, then the end-user should copy the same value across all variations of that word's alias group for the current as-is templates to pick up on the different names. So, for neighbourhood, its value would have to copied to aliases [suburb, city_district, commune, district, quarter, borough, city_block, residential, commercial, industrial, houses, subdistrict, subdivision, ward].
   • It's not enough to just have 2 copy values, aka between an input alias and its default equivalent. For example, if the input had subdivision, and generic9 was being used, then a copied value for subdivision (alias) and neighbourhood (default) would fall short because that template doesn't consider either of these keys; hence the need to copy the value across all aliases and the default, to accommodate for not knowing what the template uses.

Please let me know your thoughts on the matter.

Thank you.

[freyfogle]

Hello,

thanks for your thoughtful and comprehensive comment. Very useful.

Unfortunately right now I'm in the middle of a very hectic period, so please be patient. I will come back to you in detail, but it may be a few weeks due to other things competing for my time right now.

More soon Ed

[msgem]

No worries; thank you for the heads up, and good luck with the other things you have going on.

[GruberMarkus]

Hi everyone!

Are there any updates on the use of aliases?

I want to add that /conf/components.yaml also contains non-unique values:

• farmland is an alias for house and place
• allotments is an alias for house and place
• residential is an alias for neighourhood and road

Shouldn't the relation between alias and name be 1:1?

[freyfogle]

hmm, yes, well spotted, I would not have expected that either. The challenge is that in OSM I have (rarely) seen cases where a certain tag is widely used to means X in one part of the world, but to mean Y in another. But regardless, having the same alias in the components file is obviously not going to solve that and rather will just lead to confusion.

I have now removed them and also added a test to Geo::Address::Formatter to ensure we catch it if it happens again.

Thanks for making me aware