[Talk-us] Change sets covering entire US?

[Mateusz Konieczny]

Nov 9, 2021, 17:30 by miketho16 at gmail.com:

>
>
> On Tue, Nov 9, 2021 at 8:55 AM Mateusz Konieczny via Talk-us <> talk-us at openstreetmap.org> > wrote:
>
>>
>>
>>
>> Nov 8, 2021, 18:07 by >> zelonewolf at gmail.com>> :
>>
>>>
>>>
>>> On Mon, Nov 8, 2021 at 11:49 AM Mateusz Konieczny via Talk-us <>>> talk-us at openstreetmap.org>>> > wrote:
>>>
>>>>
>>>> Nov 8, 2021, 13:18 by >>>> zelonewolf at gmail.com>>>> :
>>>>
>>>>> I don't have a problem with the large size of the bounding box, as it is clear from the changeset description what the change is, and it is topically consistent (i.e. - it's not a changeset with a park in New York, an ice cream shop in Albuquerque, and a river in St. Louis!).
>>>>>
>>>>> I *DO* have a problem with the change itself, as name:en is redundant when the name is already in English.  The data consumers that I'm familiar with (namely, OpenMapTiles, and my own service) that are tasked with extracting names in English are perfectly capable of looking for name:en first, and then falling back to name if name:en is not present.  So IMO, this is tag bloat.  I have added a changeset comment requesting an explanation for the change and will link to this discussion.
>>>>>
>>>> It is not really redundant as soon as you make a bit more interesting name display.
>>>>
>>>> if someone would want to display names in English but in case of English name being
>>>> unavailable, show German name (which would be preferred over say "京市北")
>>>>
>>>
>>> That's a reasonable use case that I hadn't considered.  It does still feel a bit redundant but I can accept that explanation.  It is probably worth adding a revision to the name=* wiki page expressing this.
>>>
>> It is already, in fact I added this already as usefulness of this info is quite surprising.
>>
>> For example it surprised me when I initially implemented this fallback and
>> started getting German names for cities in Poland (typical case of software doing
>> what instructed, not what intended).
>>
>> So I am not surprised that it is not known more widely.
>>
>> https://wiki.openstreetmap.org/wiki/Names#Repeating_name_with_language_specific_tag
>>
>> Feel free to edit it if something is poorly written there, maybe it should be also qualified
>> that such explicit language tagging is not fully accepted.
>>
> I still do not see the value in this mechanical edit which, as I understand it, simply copied the value of the name tag to name:en for all of the cities in the US. If necessary the data user/consumer could have done the same thing.
>
The difference is that for human it is obvious "oh, cities in USA are all having name
key in English" (if that is not blindingly obvious and can be wrong - then 
edit definitely should be reverted).

But while such logic like "if city in USA, then copy name to name:en" can be applied
on its own by data consumers, rather by expressing it in OSM data it:
- needs to applied by every single data consumer
- is not always actually possible to implement it
- will be added only after someone spots that cities in USA unexpectedly
show with German/Polish/whatever labels for specific data consumer

That above was more general. Obviously edit can be reverted due to not 
following rules. Or risk of poor data, I am unable to fully judge this part.

I just wanted to explain why such apparently pointless duplication can make sense
and can make OSM data more useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20211109/56bb27fd/attachment.htm>