Talk:Any tags you like

Section "Syntactic conventions for new tags"

Right to put this here? There are some proposals in the air right now that introduce or make use of Yet Another Separator for the key part, and I thought it might be generally useful if people knew/documented what possible interpretations of a complex key already exist. Not that there are any really formal ones yet, of course.

Do people basically agree with the explanation, BTW? It's sort of what I've been using in the past, and what I've inferred from what other people do. Might be incorrect, but hey: one person on IRC seconded what I wrote... --achadwick 21:34, 1 January 2009 (UTC)

Yeah in general whenever I see proposals for tags with ':' separators (or worse, other new separator ideas), it's people who are thinking about it so much that they've lost sight of the main thing. The number one priority here: keeping editing simple for beginners. The community has a long tail shape. Every time we jack up the complexity, even slightly, that's thousands of new users who are put off editing. The page does make the KISS point. Looks good. -- Harry Wood 11:33, 22 September 2010 (BST)

Perhaps it could be separated out into a linked page, maybe with or alongside some blurb about semantics. At the very least, being able to link in proposal discussions to some vaguely well-established explanations of what kinds of things should go in tags keys, why to keep it the syntax simple, and what "all those tags on an object" mean together might help prevent some syntactically ugly or semantically broken schemes - and patterns of tagging that deploy their use in a widespread way - from emerging. --achadwick 16:21, 15 June 2011 (BST)

Semantics

Perhaps a few notes on tagging semantics should go somewhere, as a guide for the lost. Though I don't know whether we should be saying much more than

1. Each tag on an object makes a true statement. A tag such as food=no means that food is not served here, but it's still a true statement despite being expressed negatively.
2. All such statements in the object's set of tags are true together. In terms of Boolean logic, they're ANDed together.
   • This means that tagsets should never make directly conflicting statements; otherwise software will become upset. Consider the original proposal for disused=yes, which interferes with every tag describing the object's current use if you're not careful.
3. A new tag on an object may refine the meaning of a previous tag, but may never contradict it, as above.
4. Sometimes tags imply things about physical properties or the services offered by an object. You don't have to be able to express an implication as a tag — tagging is quite a loose art, and implications sometimes vary by country — but if you can, you may override such implicit meaning.
   • For example, an object tagged amenity=pub might be said to imply that it may serve food (or might not). Adding food=no clarifies and refines this. It's even OK to contradict or override something that might be implied by another tag, but all explicit statements made by a tagset must always be internally consistent.

I hope that make sense. Are there any widely deployed tagging schemes that make internally-inconsistent statements out there? --achadwick 16:43, 15 June 2011 (BST)

Characters to use or avoid in keys/values

Doesn't mention period ("."). Just like some other letters this one is used in regexp search patterns and might make some queries more difficult or return surprising results. The letter does not appear to be used in any approved key/value so I would add it here? RicoZ (talk) 10:16, 24 August 2014 (UTC)

Hmm, could you please explain why you think this is a problem? If you want to search for a "." (by using a regexp) you just need to escape it (\.). Do you think this is too hard and justifies a restriction of the chars in tags? --Aseerel4c26 (talk) 10:41, 24 August 2014 (UTC)

You could also escape all the other special letters in the same way so maybe they should be also allowed? I don't have an opinion on this but noticed a little inconsistency and it seems that keys/values with a dot are not in use aynway so it might not hurt to clarify that. RicoZ (talk) 12:18, 24 August 2014 (UTC)

Maybe I should have read the section again before commenting, sorry, I did not and my memory was too poor. Thanks for the pointer. Since the list on the page is quite a loose, non-binding collection, yes – adding more potential troublemakers (with short explanation why) should be okay. By the way, there are more meta characters: [ ] ( ) { } | ? + - * ^ $ \ . (wikipedia). --Aseerel4c26 (talk) 15:56, 24 August 2014 (UTC)

The section would have to be clarified regarding what kind of values it talks about. There are values with . (decimal separator), values with <>() (conditional tagging), values with +[] (opening hours), values with | (lane tagging), and more. --Tordanik 16:51, 24 August 2014 (UTC)

Some of the above quoted meta characters will only cause trouble in very special circumstances, "-" only in unquoted brackets and "-" is in some approved tag values (which was why I stumbled upon this).

True - it needs clarifying what kind of values it talks about. fixme and name take almost anything. RicoZ (talk) 19:42, 24 August 2014 (UTC)

In any case, users shouldn't go around deleting tags with keys containing characters not endorsed by the listed conventions; only if there is a better alternative tag with existing software support, changing to a more widely used alternative is possible. These are just hints for users if they are thinking of entering data that they think should deserve global usage. Local tags can be in the local language, parsers must cope with any UTF characters anyway, even if they just discard them. Alv (talk) 19:55, 20 April 2015 (UTC)

What not to map

The page should make it more obvious that it is about the openness in inventing tag structures, not about tagging anything somebody wants to map. So far it gives "perceived WLAN signal level" as example, we should also include not mapping individual opinions or violating the privacy of people. --Polarbear w (talk) 18:15, 7 February 2018 (UTC)

Language of new tags

I had originally suggested this at Good practice but someone suggested I come here. I was thinking in the "Syntactic conventions for new tags" and/or "Syntactic conventions for new values" section it might be good to mention that you should use English for tags and values where possible. For example, I saw someone in Tunisia add a lot of French language values for English keys which should probably translated, such as sidewalk=n'existe pas, smoothness=bon, surface=enrobé (example here: v1 at bottom), which should probably just be "no" "good" and "asphalt" but there wasn't something written down to point them to that said that. --Awiseman (talk) 00:07, 2 August 2019 (UTC)

I've edited this page to mention that keys and the values of features should use British English, when possible. I've read this in many comments on proposals and heard it on the tagging list; it also is true of almost all common tags in use (though there are a few in American English or a non-standard wordind) --Jeisenbe (talk)

Thanks, sounds great --Awiseman (talk) 16:59, 2 August 2019 (UTC)

Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

Currently the section "Non proposed features" in Proposal_process mentions that new tags should not be added to Map Features without discussion. Some users also believe that new tags should not be documented under the feature wiki space with "Key:New_feature" or "Tag:key=value" pages, but should instead be documented in a User:username/ namespace or the Proposed_features/ namespace. However, occasionally new wiki pages are created in these standard spaces for tags with only a few uses or no uses in the database.

The current text of Any tags you like suggests creating a new tag for bird nests (as an example) with Key:endangered_nest=Siberian_flying_squirrel - besides suggesting using non-standard capitalization in the value, this suggests creating a new Key: / Tag: page directly, rather than using User:username/ or Proposed_features/. Is this a good idea?

I would encourage mappers not to create new feature pages for tags which are not yet in use, or have only been used a handful of times by one mapper. Instead, it would be good to clarify that the Proposed_features/ namespace can be used even if the user has no interest in continuing the proposal process. I would recommend that new feature pages only be created to document "in use" tags that have been used by more than a handful of different mappers in more than a handful of places. --Jeisenbe (talk) 01:57, 15 August 2019 (UTC)

Different example?

"For example, if you wanted to map all nests of the endangered Siberian flying squirrel you'd just create a page endangered_nest=Siberian_flying_squirrel and document on that page what it is used for."

I propose to switch example as mapping nesting sites of endangered species is often problematic or counterproductive Mateusz Konieczny (talk) 10:25, 20 November 2023 (UTC)

agreed —Dieterdreist (talk) 10:34, 20 November 2023 (UTC)

Make clear that documentation is not mandatory

While it is recommended, it is not mandatory to document all ATYL tags. You can also use ATYL tag without documenting it. It turns out that some people are confused by current phrasing, I propose to clarify and explicitly mention it Mateusz Konieczny (talk) 10:26, 20 November 2023 (UTC)