Fortunately, Nominatim does expose `border_type` in the `extratags` field of
the response, and both Overpass queries (for nearby and enclosing features)
include all the element’s tags.
Unfortunately, `border_type=*` values are unlocalized and un-namespaced. We’d
only be able to pretty-print the snake_case keywords in English. The forum
thread discusses some potential solutions. The simple solution would be to
define `geocoder.search_osm_nominatim.border_types.#{border_type}` strings for
the most common values of `border_type=*`. This would require every
localization on Translatewiki.net to come up with a single word that
corresponds to each English word. In some languages, this can be quite
difficult for generic words like
“[town](https://en.wiktionary.org/wiki/town#Translations)”. I’m not sure it
would be received by the community any better than the current `admin_level=*`
labels.
Fortunately, the Nominatim result comes with a `country_code` field, so we
could prefer more specific string keys like
`geocoder.search_osm_nominatim.border_types.#{country_code}.#{border_type}`,
falling back to a more generic
`geocoder.search_osm_nominatim.border_types.global.#{border_type}`. We could
either introduce the per-country keys as needed or come up with a more
comprehensive list of common `border_type=*` values per country. The latter
would put much more of a burden on translators. I’ve seen that in the iD
project, where translators have to localize each part of an address field for
every country.
Unfortunately, the Overpass queries execute independently of each other, so the
results for nearby features won’t have any context about the containing
country. Since the response is handled on the client side in JavaScript, we
could parse the enclosing features results for a country boundary, whenever it
arrives, and patch up the labels on the enclosing features. In the meantime,
these labels would use the global strings. Kind of icky, but I guess it could
work.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/5450#issuecomment-2566049746
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/issues/5450/2566049...@github.com>_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
