Proposal talk:Omitted name tag

Link to a Wiki

Perhaps the right approach is the noname tag should no no more than link to a wiki page much like this one, where the relevant debate and history can play out over time. Bryce

It should be available to any tagging

Hi @ZeLonewolf:. Addressing the completeness challenge and providing mappers with a very suitable way to describe why they weren't able to fill name is waited for a long time so thank you to spend a little time for that.

However, it's not only for name=*, it's for many keys, depending on which feature we contribute: no name, no ref, no width, no surface, no voltage...
Following the opportunity to sustainably reinforce our tagging with this proposal, I would be looking for a namespace prefix or suffix, suitable for any tagging, with defined values as proposed ones.
noname=* is too specific to be generalized but covers a very wide OSM topic. I don't think it's actually desirable to define a double to every key as a consequence. Fanfouer (talk) 16:35, 16 July 2023 (UTC)

@Fanfouer: As I understand this proposal, it is needed because automated machine processing requires it to choose some other key for rendering, depending on the reason. For general human-readable reason why some expected tag is not able to be added, it is usually not needed, but can be provided in changeset comment if one finds it useful. Or, if there is a need to detail that some expected key is missing on a per-object basis, there is e.g. ref:signed=no and similar tags, and also for general human-readable comments to other mappers why something is mapped/tagged/not-tagged there is note=* (and its other instances like surface:note=* etc.) which can be used already --mnalis (talk) 01:28, 17 July 2023 (UTC)

It sounds inconsistent to me to state that name=* requires a machine readable solution to be processed and propose a human readable only solution for other keys. Machine readable solution is required for any key, not only name. Quality assurance tools, quest-based completeness apps and so on actually get benefits from machine readable solutions, instead of spending time to define the exact same logic for different things in always different fashions at different times. ref:signed=no is equivalent to something more generic like no:ref=unsigned. The last has the advantage to be expandable for many reasons instead of a single one. Fanfouer (talk) 09:27, 17 July 2023 (UTC)

noname=no might have valid uses

This proposal made me think of a lake that I encountered while mapping a while back: https://www.openstreetmap.org/way/232201214

The lake is called "No Name Lake"; that's it's official name according to GNIS. At the time I added a note=* to the way to clarify that "No Name Lake" was the real, official name, and not a tagging mistake. But after reading this proposal it occurred to me that maybe noname=no could be used for that purpose.

Searching for "No Name" in GNIS turns up a surprising number of other U.S. places that appear to have "No Name" in their official name. And searching for synonyms in Nominatim also turned up some interesting examples, like the hamlet of Nameless, Texas. It seems possible that mappers (or data consumers, for that matter) might incorrectly assume that these names are tagging mistakes and remove them.

I'm not sure how much of a problem this is in practice, and even if it is a problem I'm not sure whether adding noname=no clarifies the situation or just confuses it further. Mappers might misunderstand the double negative, and data consumers might naively interpret the presence of a noname=* tag to mean the feature has no name, without inspecting the value. But I thought it might be worth considering. — Jake Low (talk) 03:20, 25 July 2023 (UTC)

goal : add noname=* value or forbid/delete name=* ?

in a very ambiguous way, the proposal says that you can omit the name=*. but these objects already have a name=*. so is the proposal that a contributor is allowed to omit name=* ? this is already the case, you may add a poi without a name=* tag or is the proposal hiding "delete this name=* that I don't want to see" behind "omit" ?

disputed vs. multiple_languages

Does this distinction belong into the data at all? In both cases a single feature is known by more than a single name of equal standing [third party point of view], might a noname=multiple do for both? Counter argument - maybe the distinction points the parser onto different paths in one over the other? --Hungerburg (talk) 20:49, 6 August 2023 (UTC)

Disputed: you risk getting killed if you use the wrong name (see, for example, "Stroke City"). Multiple languages: no such risk (see, for example, a certain large city on the Bosporus). --Carnildo (talk) 20:10, 7 August 2023 (UTC)

A bit less a movie plot: By law, you are not allowed to enter Iran with a map based on openstreetmap data as of now, if the executives happen to control you for that, you may delete the app, throw away your mobile/GPS unit or stay out. For them, the naming of that gulf is in no way disputed. They might perhaps allow multiple, as the other side indeed calls it differently, in fact, they cannot prevent them from doing so. --Hungerburg (talk) 22:18, 7 August 2023 (UTC)