There is an article How to invent tags written mostly back in 2010, which is a kind of official guideline for making new tags and tagging schemes. An “official” - at least because it’s linked from Any tags you like article, describing one of the fundamental principles of OSM. But it seems like a very minimalist guide because it covers only a small fraction of mistakes. It even gives certain unclear tips, which could be easily misinterpreted. It also tells about “don’ts”, but just a bit about “do’s”. I’d like to discuss it here, just because writing something on Discussion page of that article will not bring anyone’s attention.

The first thing anyone must do before introducing or proposing a new tag is to do a research. There are tons of officially approved, just documented, poorly documented and undocumented tags introduced by unknown contributors. Obviously, it’s not so easy to find common entity which could be added to OSM database, while there is no tag for it. Therefore, the best way to do initial research is to use Taginfo, Wiki search and regular search engine queries with special keywords such as site:openstreetmap.org and site:wiki.openstreetmap.org for Google. It’s better to use different keywords, even barely related to tag you want to introduce. Then, it’s important to thoroughly examine everything you’ve got from search: keys, values, descriptions, statistics of usage and schemes/methods of tagging.

A good example of skipping this step is the recent proposal of leisure=aquatics_centre. There already is the way to tag it with leisure=sports_centre sports=swimming (however, it’s not ideal, but it doesn’t matter in this exact case because proposed tag doesn’t address any issues of a current scheme). An author either wasn’t aware of this existing method or ignored it (these are just two possible reasons, I’m not speculating about his intentions here). In general case, research should help anyone to discover any existing methods of tagging.

Speaking of different keywords, it’s important to understand, that English is quite diverse. And it’s not only about color and colour, center and centre. Sometimes, semantics is quite different. A good example is shop=furnace. Likely, this tag was introduced by someone from the United States, because it was supposed to be a heating equipment store, not industrial metal melting/heat treatment equipment store. Should anyone be surprised, that contributing into an international project by introducing new terms requires certain linguistic skills? I don’t think so. But for people, who invented building:facade:color= or megalith_type=grosssteingrab it wasn’t that obvious.

Regarding of any new key, it should be required to explain, which exact property of a real-world object it describes. Otherwise, we will get more keys like memorial= which specifies a “kind” of memorial (could anyone, please, explain, what is a “kind” exactly?), so we have values for both design (stele, plaque) and for an event it commemorates (war_memorial). Usage of kind, type, sort of anything in descriptions is extremely bad manner, even if you giving an example.

A similar thing applies to values: any new value of key should be homogeneous with the existing ones. Therefore, no stele and war_memorial as values of the same key. Just think about it: how would you tag a stele, built in memory of war?

Value war_memorial of memorial= key is an example of semantic redundancy, because “memorial” is repeating. Another bad practice, not covered by original guide.

Same article also recommends to use descriptive names like hiking_trail, instead of just trail. This example looks misleading - there probably could be trails for other purposes, therefore, having the whole bunch of *_trail tags is not a good idea. Would it be better to have separate key for trail purpose? Probably, yes. Here, that preliminary research helps to find out, if there are other purposes or something.

Original article says: “Avoid elaborate classifications”. Elaborate is not bad, if objects, described by it, are complex enough. Example given there illustrates redundant, not elaborate classification. Complex classifications could be required to describe certain things, just because of nature of these things. You can’t have less classes (values, for example) for something which actually has many different variants. Generalization works sometimes, but it’s not necessarily acceptable decision. For sure, redundancy is a bad thing, but it’s better to explain that properly.

This article also doesn’t tell anything about extending an existing schemes. Another (very common) issue, not covered there, is a problem value lists. Key sport= gives a good example: if there is a leisure=sport_centre or leisure=pitch, it’s impossible to tell, that you can play both volleyball and basketball there. Only option for multiple sports is multi. Theoretically, there is a way to have value lists by using semicolon separator, but people rarely do that because it’s rarely supported by styles and converters. Good practice is to have several keys in the same namespace with yes/no/unset values, just like Healthcare 2.0 uses for different medical specialists.

There are many other common issues, but I think, I already said enough to explain what I’m talking about.

As usual, I just have to say, that my intention is not to discuss specific tags (mentioning any bad scheme often leads to that), but to discuss the problem of better guide for making new tags.