This article was originally published in collaborative IT magazine Habrahabr.ru in Russian, but I believe, it would be interesting to read it for those who can’t read Russian too. So, here is the translated version (everything is okay with permission to translate and publish it here). My own notes and additions are enclosed with brackets and formatted with italic font like [this].

---

Those who are familiar with OpenStreetMap, should also be familiar with a couple of core principles of this project: «any tags you like» and primary role of geodatabase, not of «updating a map on the front page of osm.org». But is everything that nice and perfect with semantic structure of that geodatabase, keeping in mind the first principle? Reading the Russian section of OSM forum, I decided to investigate this situation.

Here are some historical facts. OSM project was born in UK. Therefore, British English is used for tags. [But you can find this fact only in discussions or certain key descriptions - there is nothing about it in recommendations for tag proposals.] So, there are leisure=sports_centre and place=neighbourhood. Sometimes you can find German words, for example to tag certain type of megalithic objects (while it is not recommended to use this tag): megalith_type=grosssteingrab from Großsteingrab - dolmen.

Tag usually consists of key (to the left from the equal sign) and value (to the right from it). It gives us a hint, that key reflects some sort of class of objects or properties, while value stands for a single type of object or exact value of property. Sometimes, keys and values are using so called namespaces. Usually, it happens in those cases, where several tags belong to a scheme, where root tag could have additional properties. For example:

• social_facility=day_care
• social_facility:for=senior

This set of tags telling us that it’s a «social facility, day care, for seniors». This principle of tagging is close to perfect, because we can have any number of additional properties, associated with root key.

Another, even more common case, is to have refinement tags without namespace. For example:

• barrier=bollard
• bollard=removable

It means «artificial obstacle, bollard, removable». From the point of view of natural language, bollard=removable sounds odd, but you should keep in mind, that OSM uses these words as abstract entities. Ideally, these entities must be thoroughly defined in details in OSM Wiki (which doesn’t always happen). Negative side of this way of making refining tags is that it’s impossible to have more than one - you can’t assign multiple tags with the same key to an object. But it’s okay to have any number of non-specific refining tags. For example, this bollard could have tags for material and size: material=concrete, height=0.7.

Until now, everything looks good and totally understandable. But, it’s always easy to break something. Obviously, any database, intended for storing structured data, querying that data, subsetting it, filtering it and so on, should have more or less uniform semantic architecture. Otherwise, it simply turns into a text. But OSM database, being intended for making derivative maps, should store data about the real world, which is perceived by many people just «as is», in form of the whole objects, without any attempts to describe them with formal properties. People just got used to talk about things they see.

Typical scenario for usage of large databases in complex projects (online stores, for example) is querying data for particular user. In certain cases it’s just some sort of parametric search, while in others - it’s so called «smart» search, that allows to associate sets of formal properties with free-form search queries.

OSM has an opposite situation: contributors are submitting data, not querying it. And every contributor does that as good, as he can, especially - in aspect of his ability to look for key features of objects. But when it combines with «any tags you like» principle (intended to ensure an ability to extend tagging scheme and to adapt it to any purpose), and usage of terms of natural language, it could lead to almost catastrophic consequences or at least highly undetermined situation.

Please, answer the question: when you want to buy certain thing, would you look for a store, where they should have it, or for a store where it might be found? Usually, people don’t want to spend their time running from store to store. But there is a lot of tags in OSM, standing for stores selling nobody-knows-what. For example, shop=kiosk. If you read the tag description, you’ll find out, that usually kiosk sells everything from newspapers to tobacco products. [and it’s varying from country to country.] So, looking for a box of cigarettes, you can or can not find it there. Only more or less clear feature of kiosk is its size: it’s relatively small. And you can’t even tell, if it’s a separate small building or something built into a bigger building. In some countries, this term is used for small shops in general.

This tag was actually copied directly from the natural language. You can thank Etric Celine for it. On his Wiki page, he clearly tells, that he is an anarchist and he disrespects the formal procedure of proposals and discussions of new tags. But in the same time, he thinks, that it’s very important for everybody to «do something». He actually did: he introduced the tag, which stands for nobody-knows-what exactly. There are almost 50000 «shops of nobody knows what» in OSM. And lots of people, who only started to contribute, and who don’t really understand, how important is to keep everything as structured as you can, starting using this tag immediately for every small store. Even if there is better tag for news agent, ice cream shop, tobacco shop and so on. Why they doing that? Because they don’t care about semantic structure, while they got used to call these shops «kiosk».

For an experienced developer or database architect, it looks completely ridiculous, that there is no way to actually tell, what classes of goods sells particular store, while there is a way to reflect its natural name such as «supermarket», «kiosk», «mall». But that’s how it works in OSM. Yes, there are tags for book stores, DIY stores and so on. In the same time, you can’t tell anything about stores with more or less universal set of goods, such as «supermarket» or «mall». By the way, it’s quite hard to tell the difference between «supermarket» and «mall». [And it brings up the question about being able to verify these tags, which is important principle of OSM.] Yes, we know, that mall is a «large building, where many shops, restaurants and entertainment facilities are located», but supermarket can have some space to give for rent to owners of smaller shops too. So, where is that border between a supermarket and a mall? Moreover, is it important at all to have different tags for them?

Majority of widely used tags have blurred boundaries of usage. For example, it is really hard to define formal difference between cafe and resturant. This difference is not in size, not in having or not having the waiters, not in menu, not in working hours, not in the way of seating, not in reservation requirement, not in price or anything else. These are just words. Sure, in certain cases, it’s hard to call some place a «cafe», if it’s a place with high rank service and so on. But where is the border? There is no border. That’s why usage of amenity=cafe and amenity=restarurant is undetermined, and it goes against the requirement of being verifiable. This principle says, that every object, submitted to OSM, should be tagged in a manner, when any other contributor can confirm it using the same source. Presence of word «restaurant» in a name is not a good criterion, because there are similar words in certain languages (like adopted «кафе» and «ресторан» in Russian), but what about other languages? What about Czech hospoda or Polish tawerna? There is no way in this direction, because it doesn’t make any sense (and also - impossible) to make a tag for any natural language term.

It is important to use an abstraction as mental instrument to search for valuable properties and to tag these properties, regardless of own habits. Only this approach allows to offer valuable and determined information to OSM data users. Only in this case, user will not have to guess, what was the idea behind tagging particular place as restaurant or cafe. Parametric search or offering the list of properties are much more user-friendly solutions compared to showing the whole list of restaurants, cafes and other places without any descriptions.

Sometimes you can see an attempt of making a kind of scientific classification, but natural language and narrative knowledge can affect it in negative manner too. Almost from the beginning of OSM, there were two tags: wood=coniferous, wood=deciduous. People [English-speakers] got used to think about these words as about opposing terms. But actually, there are deciduous and evergreen trees. And trees with leaves and needles. So, there is European Larch, which is deciduous, but it has needles and cones. Also, there are different Laurels - evergreen tree with leaves. Recently, old tagging scheme was replaced with a new one, clearly reflecting shape of leaves and seasonal changes of foliage.

Another situation, where lack of knowledge gave us unclear and contradictory definitions, is the case of masts and towers. These objects are tagged with values of man_made=* key. In structural engineering (area of knowledge, covering all types of man-made structures) towers are free-standing narrow vertical structures, supported only by its foundation. While masts are narrow vertical structures, supported by guys and anchors. That’s quite simple and in addition, these terms are international. But other areas of technical knowledge are less strict about it. So, power company workers could call everything a mast. As a result, these two tags are used in unclear manner. [Pictures, given as an example on Wiki page are ridiculously non-descriptive.]

The most ridiculous (and, in case if it spreads - the most negative, because of semantic divergence - coexistence of several different readings of the same tag) situation is when a word, used for certain key or value, has completely different meaning in different languages. There was a case recently, when Russian-speaking contributor tried to propose a new property for restaurants to reflect that you can have «business lunch» there. Ridiculousness of this situation is that only in Russia this term (coined in the nineties of the 20th century) means «lunch for fixed price». In the rest of the world, terms table d’hôte and fix-price are used for it. Obviously, in the rest of the world, business lunch means something about having lunch and conversation with business partners, not a type of service. For sure, words, used for keys and values are abstract. But these words should be understandable for other contributors, at least to have some correct general idea of what it means. [There is another case of similar nature: one of Russian contributors invented new values of office= tag - office=administrative, but his English skills didn’t allow him to translate his definition properly, therefore, we have completely opposite definitions in Russian and English Wiki.]

It works in opposite way even more often. Foreign words are rarely adopted without any changes in semantics. Therefore, those people, who are not familiar with British or American culture, pretty often making mistakes because of wrong reading of some word or because they are not aware of consonance. For example, some Russian-speaking contributors sometimes getting confused by highway=service service=alley. English word alley sounds similar to French allée and Russian аллея. Russian one was adopted from French, and it stands for a street with tree rows. English alley is a narrow passage between or behind the buildings. [There is no alleys in Russian/Soviet architectural tradition] This is why some Russian contributors trying to use highway=service service=alley for promenades.

Even withing the English-speaking community, certain contradictions could happen. Just think about drugstore and pharmacy.

Another case is usage of words cabin, hut, for values of building=. These tags should denote type of buildings. But there is no clear difference between them. And there are associations. Americans will likely associate cabin with small isolated house, given for rent. Norwegians will associate it with hytte of Den Norske Turistforening or private one. Same thing with people from Switzerland and mountain huts of Schweizer Alpen Club. I mean, people could compensate the lack of clarity with associations. Russian contributors used to use these tags to tag traditional log houses, while you can still clearly tag them by using building=yes, building:material=log.

Certainly, semantic chaos of natural language doesn’t affect the whole project, but it is significant. There are successful cases of making good classifications to replace old unclear schemes. One of these cases is Healthcare 2.0, created to describe all features of medical facilities and medical help and to get rid of amenity=doctors which means nothing. [Ironically, this scheme didn’t make it through the formal proposal procedure.] Pretty remarkable job is done by one of Russian community members to create forestry management scheme. Unfortunately, it doesn’t even have own Wiki page, currently sharing it with deprecated wood= tags.

New well-designed schemes are usually not depending on language or cultural context. To adapt it to another context, it could be enough to add only a couple of values. For example, Healthcare 2.0 allows to describe medical facilities, specific for Russia, even keeping in mind that authors of this scheme were not aware of these facilities completely. That’s a power of using elementary properties you can combine in any required manner.

The most sad aspect of this situation is that even many experienced contributors don’t understand this problem, thinking it’s something unimportant, or claiming that solving this problem will create more barriers for newcomers and deter newbies (that’s pretty common argument, because nobody knows anything about their patterns of behavior for sure, so it’s easy to speculate about it).

But actually, if there is a new more clear scheme, it’s easy to start using it to map those objects it was impossible or inconvenient to map before. OSM exists to create free geospatial data, not to make a nice club. So, if for someone it’s easier to light-mindedly map things using unclear ineffective schemes, but it’s too hard to use clear and effective ones, quality of his contribution is highly questionable. In the same time, people who don’t like current schemes because of semantic issues might increase their contribution in case if better ones would be available.