In a JOSM ticket (#21917 ('except' tag in the turnrestrictions plugin) – JOSM) a comment indicates that having a wiki page for each tag is not useful; however, I feel the opposite, and I would like official position of the wiki (which I haven’t found).
I have seen that some JOSM plugins are inserting keys that are not “de facto”, nor “approved”, and this is forcing to use unapproved tags (except=bicycle). This confuses a lot to the users, and that could lead to problems in other applications.
I would like to know what is the right process to include a tag in the official editors like iD or JOSM compared to the Wiki?
3 Likes
As far as I know, the wiki has no unambiguous position on this. The wiki guidelines have a section on avoiding duplication, but that’s sufficiently vague to require a case-by-case judgement.
If the meaning of a tag can be described in a couple of lines on a suitable overview page, I would personally avoid creating a separate page for it.
1 Like
It’s not much different than OSM’s tendency toward increasing detail: originally, many common tags didn’t even have their own pages, but over time, as we’ve needed to discuss each tag in more detail, splitting out pages reduced confusion compared to maintaining redirects to a larger page. For example, until recently, pages for addr:city and addr:postcode redirected to a page about the (nonexistent) addr key.
For start, note that opinions on JOSM issue tracker or here are DEFINITELY not “official position of the wiki”.
I am not aware of any specific rule of OSM wiki that would forbid making pages about specific tags.
Personally, I consider it highly useful to have description of specific keys (for example name:pl or short_name:pl or cycleway:both or parking:condition:left:maxstay) even if it mostly mentions where documentation can be found, as it makes feasible to check status of specific tags.
For example, I created parking:condition:left:maxstay while implementing support for parking lane tagging and it was result of several minutes of jumping across wiki/taginfo/data, as status of that tag was not obvious at all.
And now it is linked from taginfo, directs to proposal where it was confirmed and has short description of it meaning and links to wider documentation (link).
If you want to establish OSM Wiki rule or ask OSM Wiki editors, you can ask at https://wiki.openstreetmap.org/wiki/Talk:Wiki ( this creates new section, available for logged in ).
Editing interface is sadly not well fitting discussion (it is the same as wiki pages!) but do not worry and just add your comments (feel free to request a technical help). Note that at least for now OSM Wiki requires a separate account.
have seen that some JOSM plugins are inserting keys that are not “de facto”, nor “approved”
that is not automatically a problem by itself, every tag was once a new one
I would like to know what is the right process to include a tag in the official editors like iD or JOSM compared to the Wiki?
request it at the issue tracker and/or implement code adding such support
a comment indicates that having a wiki page for each tag is not useful
I disagree, having wiki page for Key:except specifically would be superior to redirect to page covering wide variety of topics.
I edited it now to point at least to a general area of page where except is mentioned, but dedicated page would be better.
4 Likes
discussion was started on wiki, likely triggered by this thread
Please comment there if you care about allowing/banning such tag pages (discussion here is not defining OSM Wiki rules)
I agree, it also makes it easier to have discussion about a specific tag in the right place, or countryspecific annotations, and it invites to augment the description, as opposed to a description on an overview page, where more text is usually not helpful because it would clutter the page.
Cheers,
Martin
This thread did trigger me into finally starting a discussion. But it is not about the example discussed here, where there are actually reasonable arguments in favour of creating a dedicated documentation page.
Instead, it is about the thousands of possible keys that result from “building block” systems such as “conditional restrictions” (maxspeed:forward, maxspeed:backward, maxspeed:hgv, maxspeed:hgv:forward, maxspeed:hgv:backward, maxspeed:hgv:forward:conditional, …). To me, creating individual wiki pages to document these seems like an obviously bad idea, but not everyone agrees. Hence the discussion.
1 Like
I do agree that for these building block systems it seems more maintainable and feasible to document the system and its parts, rather than all the possible combinations.
My comment was more aiming at sub-sub-tags, something like statue=equestrian, which assumes there are also historic=memorial and memorial=statue tags, or maybe tourism=artwork and artwork_type=statue, and which would initially often be just listed on the memorial or artwork page, but later get its own page.
Cheers,
Martin
2 Likes
When I was saying to have a wiki page for each tag, I also meant to have an “item” entry in the wikibase (like https://wiki.openstreetmap.org/wiki/Item:Q35 that explicitly explain where to map it, how, etc.) and be listed in the Map features page (https://wiki.openstreetmap.org/wiki/Map_features#Additional_properties).
By not having an item entry, these invented tag will never be visible from editors like iD, because it access the wiki documentation by a query. Also, app developers will not be aware of these tags, and they won’t interpret them on their tools; for this particular case, the tag “except=bicycle” will only have a meaning when using a specific plugin in JOSM.
Also, I want to know what is the purpose of a “Proposal process” if the developers of the most important tools do not follow it, but create its own set of tags?
So, my question was not only about the corresponding wiki documentation, but also related to the impact of the integration with other tools.
2 Likes
Proposal process usually involves review of what was proposed by other mappers, as result some issues may be caught before tagging scheme is widely used.
the developers of the most important tools do not follow it, but create its own set of tags
This situation is fortunately quite rare.
By not having an item entry, these invented tag will never be visible from editors like iD
They will be visible in dropdown suggestions if in noticeable use and can be added to iD presets.
When I was saying to have a wiki page for each tag, I also meant to have an “item” entry in the wikibase
This is called “data item”, “wiki page” refers rather to page on OSM Wiki such as Key:addr:* - OpenStreetMap Wiki
This is a complicated question to answer. Certainly the proposal process has had its successes over the years, but there are plenty of approved tags that the community has later had second thoughts about, or explicitly rejected tags that gained traction in OSM because it was a good idea (not necessarily because any editor added support for it). You could think of an approved proposal as an endorsement by what’s often a very small slice of the community, but not an automatic assurance of adoption.
Not every editor uses the same set of presets or fields, although most mainstream editors are aligned with either iD or JOSM. The presets for iD and iD-influenced editors are maintained in the id-tagging-schema repository, which welcomes bug reports and contributions.
except may not be particularly common on its own, but it is part of the extremely common turn restriction tagging scheme, which has documented except since 2007. Just about every router understands and relies on this key to exempt a certain vehicle type from the restriction, making it as much a de facto key as one with many more occurrences in the database. Especially when it comes to navigation-related keys, backwards compatibility is an important consideration, so existing software support is a strong precedent.
It is possible to express except=bicycle differently, via subkeys like restriction:motor_vehicle=* restriction:carriage=* etc., but that requires intimate knowledge of the access key hierarchy that almost no one possesses. except better reflects how these restrictions are typically signposted in the real world, with “Except” plaques beneath the restriction symbol.
2 Likes
Since there’s no such thing as restriction=none, the turn restriction sign below would be most succinctly expressed as something like restriction=no_left_turn except=bus except:conditional=taxi @ (01:00-05:00). Or if that would cause buses to be prohibited from making left turns in the early morning hours, then I guess it would be something like except:conditional=taxi @ (01:00-05:00); bus @ 24/7.
1 Like
I think part of the problem is the practice of only documenting tags approved through the proposal process. This leaves large collection of customary tags undocumented. My hope is that each community can start by adding wiki pages for thier commonly used tags. Besides helping mappers find the correct tag, it will gradually reduce the number of ad hoc tags without some type of description. It should help bring visiblity to groups with specialized knowledge or regions with different cultural understandings. This should lead to a reduction in fragmention and the number of effectively duplicate tags.
1 Like
Documenting tags that are used but not went though approval process is commonly done.
Problems are present only where someone is trying to redefine tags this ways or has habit of “documenting” tags with no or minimal use.
2 Likes
you can do it, and it is done. Tags that are used should be documented, regardless of proposal status, and if they are obsoleted of disputed or something else seems wrong with them, this information should also be added
2 Likes