Comment is requested on a proposal to introduce two tags to indicate the reason why a name=* tag has been omitted from a feature:
https://wiki.openstreetmap.org/wiki/Proposal:Omitted_name_tag
1 Like
The proposal currently states:
Iām not sure this is always the case. I have occasionally encountered and removed noname=yes tags where a visitor to an area have marked a street as having no name, but where I know that it will have one based on the way the area was developed, and the sign was probably just missing (they tend to blow away in severe storms). If noname=no was documented I would probably use this value along with name:signed=no to record this situation rather than just deleting the tag.
4 Likes
Like that name:signed=no (15K uses is respectable). Countless ways and squares have no names showing but we know they have, often same name as the hamlet, so San Callisto becomes Via San Callisto. Fortunately if not a corner pole or wall sign thereās often the house numbers with the street name printed below in which case Iād add tag source:name=address or a company register, or local knowledge, often stop to ask a passer by or person in house front garden, and then research for confirmation.
The noname=disputed I see to have immediate utilityā¦ way south thereās a longer name dispute going of names per corner signs versus names per deliberation. This one is now at version 8.
1 Like
Hi
As mentioned in proposal Talk page, this topic should be addressed in regard of any tagging.
No valid reason, except experimenting new solutions, make such a capability restricted to names.
We should have a similar tool for any key we are actually unable to fill on a feature we had surveyed.
noname=* was a useful contribution to try on but should be replaced by a more global approach of uncertainty in tagging.
This proposal is an opportunity to discuss it.
Best regards
Thank you for describing this use case. Itās something I hadnāt thought of. I could see noname=no meaning āthere is no name tag because the name has not been determined yet, however, there is a name.ā
I think this is a great idea, and we should have some kind of prefix to indicate the reason why any tag is missing. However, noname=yes has achieved 700,000 usages, and is supported by multiple data consumers. Therefore, I think we are realistically stuck with the noname key for describing this situation with the name tag.
I would absolutely support a general case prefix along these lines, but for this proposal I intend to keep it narrowly focused on name and noname.
Were we stuck with waterway=riverbank when it had more than 350 000 occurrences?
I wonāt support defining some values for names and defining the same in another fashion for other tagging.
Nothing forces us to improve values for noname=* instead of defining the global framework now.
noname=yes is here and could easily be moved softly or automatically to what we could propose.
Yes it could, and if thereās clear consensus to do that, I will absolutely change the proposal to match. It would involve double-tagging, a wait period for data consumers to catch up, and then a removal later. With waterway=riverbank this process took 13 years and a massive project to complete. I merely completed what @Zverik started.
However, historically the community has opposed attempts to rename tags solely for the purpose of making them more consistent, and itās that opposition that guides my choice to use the existing key. So I stand by to hear how people feel about the idea of deprecating noname in favor of a more general solution with those caveats noted.
1 Like
For anyone following this, what I believe @InfosReseaux to be describing, just to put a pin on it, is a scheme whereby tagging would be something like:
omitted:<key>=<reason>
Thus you might have omitted:name=disputed or omitted:name=multiple_languages to be consistent with the goal of this proposal.
2 Likes
Note that I have not suggested to deprecate noname=* for now.
The point is to invest our time in this proposal to introduce a more global solution, not to reinforce what is known to be too specific from the beginning.
We could deprecate noname=* later, once the new tagging has been experienced and adopted.
Multilingual name tags, like name=Morze BaÅtyckie - Baltijos jÅ«ra - Baltijas jÅ«ra - LƤƤnemeri - ItƤmeri - Ćstersjƶn - ĆstersĆøen - Ostsee -ŠŠ°Š»ŃŠøŠ¹ŃŠŗŠ¾Šµ Š¼Š¾ŃŠµ for the Baltic Sea, normally contain the names of the object in the languages spoken by the people living around it. Contrary to what the proposal says, if we suppress this name tag and replace it by noname= multiple_languages data consumers would not be able to build this list of names. How could they know which of the 53 name:xx tags to use?
There have been many discussions on this topic, mainly concerning bi- or trilingual territories and, if I remember correctly, they all ended up with a hyphen or slash separated list in the name tag as solution.
1 Like
There have been many discussions on this topic, mainly concerning bi- or trilingual territories and, if I remember correctly, they all ended up with a hyphen or slash separated list in the name tag as solution.
I really donāt get why the multilingual data should be in the same key with semicolon / slash as separators.
Arenāt name:<language>=* enough?
If the reason is to tag for the render (i.e display every language in the displayed name), itās a very bad practice and solution should have been implemented in the render software itself.
3 Likes
Contrary to what the proposal says, if we suppress this name tag and replace it by
noname= multiple_languagesdata consumers would not be able to build this list of names. How could they know which of the 53name:xxtags to use?
they should use all of them, naturally. According to their users they will choose the appropriate language(s)
I gave you an example above. A look at discussions about name tagging in South Tyrol (Trentino/Alto Adige) or bilingual Swiss cantons may provide additional information.
Each renderer who wants to display names as used by the local population would need its geographical database with information about the lingual situation for any point to be rendered. I as a renderer would expect this data from my geographical data provider, OSM in particular.
Removing name from features which do have a name (in multiple languages) would harm data consumers who just want the local name (however that is decided) or a guaranteed fallback for when a preferred set of languages doesnāt have a corresponding name:*.
Instead of omitting name because it is disputed, why not document that it is and give data consumers who care the option to decide based upon that information?
E.g.,:
place=ocean
name=Atlantic Ocean
name:en=Atlantic Ocean
name:ja=大č„æę“
name:status=global_fallback: en
Something like that. global_fallback cases would be rare, and mostly limited to things like continents and oceans.
Compound names, much more common, could then (optionally) do this:
place=country
name=Belgiƫ - Belgique - Belgien
name:nl=Belgiƫ
name:en=Belgium
name:fr=Belgique
name:de=Belgien
name:status=multilingual_compound: nl;fr;de
(Some might even have name:status=disputed like this islet, where name:status:note could then expand on the nature of the dispute for human consumption.)
That way the nature of disputed or complex name values can be codified, and data consumers can act on these if desired, including omitting them.
A suffix-key like this (not necessarily :status, a better name is probably possible) would work for any other name value as well, including alt_name or name:tok, or what have you.
1 Like
Another benefit of having this information available, is that it enables data consumers to create their own compound name label using name:* and that list, but with a different separator, different ordering, or limited to some of the languages listed.
This discussion of documenting the list of local multilingual names for a feature is interesting, but is off-topic.
The proposal, and the problem Iām trying to solve is specifically about documenting the reason that the name tag is omitted.
2 Likes
Sorry, the use of āBaltic Seaā as an example in point 1.2 of section āRationaleā in the proposal was confusing me and still does. Is the proposal to keep the multilingual name tag and add noname=multiple_languages or to suppress it and add noname=multiple_languages instead?
It would mean omitting name is not necessary at all for the stated goals. Having name for named entities is a rather strong convention; not deviating from that benefits a lot of use cases. How is that off-topic?
Documenting the nature of a disputed or complex name means noname=yes can keep its meaning of marking the absence of a name; i.e. where something really does not have a name in reality.
1 Like
I like the idea of tagging āThere is no name tag because there are multiple languagesā. However using noname=* key seems backwards. For (some) languages there is a name, so (to me) you canāt say it has no name.
I encountered a similar issue, when trying to tag that a river didnāt have a Wikipedia page. and used no:wikipedia=yes.
My suggested tag is missing:name:reason=multiple_languages, or name:missing:reason=multiple_languages.
I prefer missing:* to prevent people interpreting :missing as a language code. I like having :reason suffix, in case one wants to expand other details about the missing name tag.
3 Likes