Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent Components Use in Worldwide Templates #116

Open
msgem opened this issue Oct 23, 2024 · 2 comments
Open

Inconsistent Components Use in Worldwide Templates #116

msgem opened this issue Oct 23, 2024 · 2 comments

Comments

@msgem
Copy link

msgem commented Oct 23, 2024

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
Copy link
Member

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
Copy link
Author

msgem commented Oct 24, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants