Тег natural=heath - очень многострадальный.

В русскоязычной документации его определение долго было просто скопировано из весьма скупой статьи в Википедии (а туда - из какого-то краткого географического словаря), при том - не полностью. Оттуда пошло обозначение этим тегом областей, которые поросли кустарником (вместо natural=scrub, который для этого предназначен).

В preset-ах JOSM коллега Calibrator, известный своими фантастическими переводами, вообще присвоил этому тегу название “Пустырь”. Плюс, неизвестно сколько участников проекта никогда не читали документацию, а пользовались тегом интуитивно, полагаясь на простонародное старинное значение слова “пустошь”, которое как раз близко к “пустырь”, в значении “вырубка”, “место, где теперь ничего не растет”.

Тем временем, исходно этот тег начали использовать в Великобритании (как и многие другие), обозначая им вполне конкретную экосистему, а не просто место вырубки. Почему этим же тегом нельзя обозначать что-то еще? Да потому, что если одно и то же обозначение может соответствовать вообще чему угодно, оно просто теряет свой смысл - никто, глядя на контур с этим тегом, более не сможет сказать, что же именно там находится, если каждый будет обозначать этим тегом что-то свое. Надеюсь, этот момент ни у кого не вызывает сомнений, а если вызывает - то я действительно не знаю, как еще можно объяснить, что так делать не следует, иначе данные теряют всякий смысл (а один из принципов проекта - вносить максимально точные данные).

… See full entry

When it comes to visual map styles, there are always some people, who worship paper maps. In case of United States, it’s about USGS topo maps, in the UK it’s about Ordnance Survey, in case of Russia - about Soviet military topo map (slang name “Genshtab”, which means “General Command”). These people always think, that symbology of these maps is something absolutely superior, because professional cartographers were working on it for many years to make it effective. Which is true, but barely relevant to digital cartography.

Here are several reasons why this extrapolation is wrong. (For some people it’s an obvious thing, but I just like to have it here in written form to be able to refer to this diary entry in case of discussions and arguments instead of typing it every time I need it.)

Any professionally developed map style is always based on several factors: main use of specific map type, map scale (level of details), media (paper or screen).

Exactly by this reason, there are many different professionally developed standards for civilian topographic maps, hydrographic maps, military maps, aeronautical charts (and they are different, depending on altitude), marine nautical charts. In certain cases, for example - in case of nautical charts - IHO standards are universal (see IHO download page, especially - S-4 document), since it’s considered safer to have uniform styles.

… See full entry

Недавняя дискуссия про highway=track и бесконечные обсуждения статусов дорог (значений ключа highway=*) подтолкнула написать это разъяснение.

Существует несколько вариантов того, как определения тегов, ключей и значений могут различаться в статьях на разных языках.

1. Различие может быть обусловлено кривым переводом и не является намеренным.
2. Различие отражает другую трактовку какого-либо тега в национальном сообществе относительно других.
3. Различие отражает более строгую или менее строгую трактовку какого-либо тега.

Что делать со случаем (1) - понятно: исправлять без разговоров, потому что чем меньше просуществует явная ерунда, происходящая от того, что переводчик плохо знает язык или вообще косноязычен - тем лучше.

Случай (2) для многих является спорной ситуацией. Действительно, а что делать, если в какой-то стране по какой-то причине тег Θ=Ψ стали употреблять для обозначения объектов B, хотя во всем мире им обозначают объекты А (при этом A и B - разные)? Тут не может быть универсального рецепта, так что это не тема для данной заметки. Скажу только, что поскольку в OSM есть принцип any tags you like, нет ни малейшей логичной причины для того, чтобы брать какой-то определенный тег и начинать им обозначать что-то совсем другое. Придумайте новый, если отметить нечем. Причина, обычно, одна: маппинг под рендер, “хочу, чтоб на карте рисовалось”. Очевидно, что это также связано с далеко идущим наплевательством: как и откуда, по мнению любителей так делать, пользователи данных из других стран (о которых, по иронии, так любят “заботиться” любители транслита в именах) должны понять, что же на самом деле так обозначено?

… See full entry

Хочу поделиться своим взглядом на перевод на русский язык и редактирование документации OSM. Может быть, кому-то пригодится. Или не нужно будет повторять аргументы в очередной раз, а просто можно будет сослаться на эту запись.

Во многих дискуссиях, начинавшихся после очередного клича “давайте все переводить документацию!” я говорил, что стремление перевести всё подряд лишено смысла. Для того, чтобы так говорить, у меня есть несколько оснований, которые подтверждены моим опытом. Понимаю, что мой опыт - частный случай, не более, однако для меня найденные закономерности работают.

… See full entry

This is a follow-up entry to certain comments I’m getting on my other entries, related to tagging scheme inconsistency. I just want to explain this in a separate entry to be able to link to it every time certain argument is used.

Every country, nation and culture has own natural language definition (or, I’d say, “vision”) of certain terms, used in everyday life. However, OSM is an international project and OSM data is used regardless of borders. Therefore, having different definitions based on local vision makes OSM data inconsistent. In certain cases it could even make it really hard to interpret. Let me give some examples:

In Russian language, word “ангар”, derived from “hangar” is widely used for quick-assembly hemicylindrical buildings made of metal and used as warehouses in industry. If you will ask anyone in Russia, what is a “hangar”, they will say, that it’s obvious and will give you that description. For person from Britain it will unlikely make any sense, since in English “hangar” means “building for keeping an aircraft in it”. So, if the same British person will see thousands of building=hangar in Russia, located quite far from any airstrip, it will confuse him. Obviously, this is completely wrong usage of building=hangar and it should be actually mapped as building=warehouse, building:material=metal, roof:shape=round, roof:material=metal, building:levels=1or something. But if you’ll try to tell Russian mappers about that, many of them will complain, that it’s “too complicated”, and will continue using building=hangar just “because it’s obvious, everybody knows, that it’s called a hangar”. I know, because I tried. Finally, I just had to re-tag all these warehouses in area I’m watching.

… See full entry

There are more than two millions of shop= key entries in OSM database. Definitely, everybody knows what “shop” or “store” actually is. But in the same time, certain vales of this key do not have any practical sense. I can even take the liberty to call these values “unusable”, because they tell nothing about what you actually can purchase in these stores.

I’m talking about shop=convenience (271k entries, top value), shop=supermarket(237k entries, second most used value), shop=kiosk (54k entries), shop=mall (34k entries).

These are “wildcard” values, indicating anything and nothing in the same time. If someone wants to find, where to purchase particular type of goods, it’s impossible to do that in case of these tags, especially - latter two mentioned above.

Malls are not shops at all - these are commercial buildings, full of everything, from supermarkets to cinema theaters and customer service or sales offices. So, every store, amenity or facility there should be tagged individually.

Kiosks are very different from country to country - just several years ago, for example, some kiosks in Russia were selling everything including strong alcohol (currently, it’s prohibited, but there still is some legal loophole, especially for countryside). But anyway, we can never tell, if particular “kiosk” in OSM database stands for something close to news agent, or it sells vegetables and tobacco products. However, building=kiosk does make sense, since concept of small standalone retail building is more or less similar in entire world.

Same thing applies to convenience stores, supermarkets and, at certain grade, to pharmacies (at least, in American meaning, since Walgreens or Rite Aid, being “pharmacies” look exactly like Safeway or Albertsons, being “grocery stores”, with just a bit larger over-the-counter drugs department and without fresh produce department).

… See full entry

It looks like the current scheme for tagging “water-containing features” has certain significant inconsistency. This scheme originates from this proposal made by @Zverik back in 2011. I completely support the idea of having some uniform scheme for more or less natural water bodies, but this proposal also has an effect of deprecation of several tags, related to artificial, man-made or even industrial objects, where water is in use.

This issue has been addressed in original proposal discussion by @G0ldfish, but @Zverik didn’t answer his question at all.

After approval of this proposal, the whole landuse=reservoir scheme has been labeled as deprecated, because supposedly, we can now use natural=water water=reservoir to tag artificial water bodies instead of using landuse=reservoir. But it’s only partially true. Indeed, water storage reservoirs are often not that different from natural water bodies. But there still are objects such as cooling basins, technical water reservoirs, wastewater reservoirs etc. Important tag reservoir_type= is deprecated as part of the whole old scheme.

Please, keep in mind, that when we have to tag a cooling basin of an industrial facility, water itself is just a part of this object. Ideally, proper tag (something like former landuse=reservoir reservoir_type=cooling) for it should indicate that there could be a concrete basin with sprinklers and other equipment. It can even use some sort of cooling liquid, which is most likely water-based, but it is absolutely not necessarily a water.

Same situation with sewage and wastewater reservoirs. It’s quite hard to call its content “a water” - water usually is a product of long filtering process, and aeration in sewage reservoirs is just a part of it. So, initially, concentrated sewage liquid can not be called “water” by any standards.

… See full entry

Quite often you can see, that somebody is arguing about certain tagging method calling it “too complicated to be used by anyone”. It is very typical thing (especially for ones who don’t care about adequate mapping, but who cares about having an icon on map).

OpenStreetMap is an international project, which makes it harder to have universal tags for everything since real-life entities are varying from one country/culture to another. This is why we have to use complex schemes.

For example, in Soviet Union governement-driven medical system we have had facilities, called “диспансер” - this word comes from French word “dispensaire” which means “dispensary”, but it is not a dispensary - it is a clinic, dedicated to certain type of diseases or conditions (sexually-transmitted infections and skin diseases, tuberculosis and pulmonary diseases, addiction to alcohol or drugs, mental conditions, oncologic diseases), which is supposed to have all required equipment for tests and treatment. Also, it had anti-epidemic functions. In USSR times, these clinics were also responsible for tracking patient’s official medical history regarding of these diseases, since there was no other option like private clinics. For example, to obtain a driver license, you had to get official papers from two of these clinics listed above to proof that you are not an alcoholic or drug-addicted and you are sane person.

As you can see, it took the whole paragraph to describe its functions. So, yes, there is an option to create special tags for each of these facilities. But will it be understandable and usable for OSM data users outside the former USSR (Russia)? Definitely, no.

But using the Healthcare 2.0 tagging scheme, it is easy to come up with this:

… See full entry

За время чтения русскоязычной ветки форума OSM, с января 2012, мне случалось участвовать во множестве обсуждений, в которых разные участники проекта в той или иной степени старались оправдать обозначение под рендер или конвертер. Делали они это, вероятно, с разными целями: одни из духа противоречия (есть такие люди, которых воротит от правил или от того, что им указывают на ошибки), другие - просто от желания “потроллить”, третьи - действительно желая видеть в подписи, вообще на карте, либо в поиске в навигаторе то, что не поддерживается или чего там быть не должно. Чтобы иметь возможность потыкать демагогов носом в то, что их риторика - глубоко не оригинальна и предсказуема, я хочу тут собрать коллекцию их высказываний. Не в форме прямых цитат, а в форме тезисов. Дополнения в комментариях приветствуются.

Да, к слову, пресловутые новички иногда вполне искренне заблуждаются, но им достаточно разъяснить все один раз, за редчайшим исключением. А убежденными сторонниками этого безобразия и самыми упорными демагогами оказываются, как раз, участники проекта с опытом.

“Данные не имеют смысла, если их нельзя найти”.

На самом деле, никто не знает всех случаев применения данных OSM, потому что нет никакого реестра пользователей. Доходит до курьеза: например, пока на форуме не поднялся шум по поводу адресации в Зеленограде, никто не знал толком, что существует, как минимум, два прецедента карт (и конвертеров), которые поддерживают тамошнюю специфическую адресацию без улиц, что инвалидировало аргументы некоторых о том, что в таких адресах нужно вставлять ложное значение addr:street=, иначе поиск невозможен.

“Данные не имеют смысла, если их нельзя увидеть”

… See full entry

Recent question of some person, who uses maps for Garmin navigation devices, derived from OSM data, brought up a good example of tagging for navigator. He was dissatisfied by his Garmin navigator (actually, BMW branded Nav V) making straight routes instead of turn-by-turn ones in case, when destination is somewhere in the end of private road, tagged with access=private. He acknowledged, that Garmin Basecamp software works okay with the same map. Then he asked about proper way to tag roads, say, in suburban residential areas, where access is limited by locked lift gate, and where only residents have a key.

Several OSM contributors told him, that it is enough to put a barrier=lift_gate node on that way and to tag this node with access=private. Wiki suggests this as some sort of “intermediate” or “minimal” tagging method too (and obviously, it doesn’t call it a “bad practice”). And it will help to avoid that issue of Garmin routing. But is it right and consistent?

First, access= key is intended to tell us, that access to tagged object is limited (or, otherwise, granted). So, tagging a lift gate with access=private literally means “this is a private lift gate”, which only partially makes sense, since you still can approach it, but you can’t operate (open) it.

Second, access regime of road is not necessarily created by physical barrier such as lift gate. It could have a sign. Or just a note. Or it could be limited by law. It means, we can’t eliminate adding limited access tag to highway-tagged way itself completely, in any situation. Therefore, it makes that scheme with access=* on a barrier node obviously inconsistent.

… See full entry

Quite often you can read a reference to newbies in discussions of almost every aspect of OSM project. Someone could use that reference to say, that something is too complicated. For example - certain tagging scheme. In other cases, it is used to motivate someone, like, “you’d better translate that Wiki page, otherwise, newbies will not understand …”

Actually, only a few references like that making any sense. Usually, it’s nothing more than demagogic method to convince others. And here is why.

For example, in marketing people conducting studies, tests, using focus groups and panels to learn about target group of certain product, service or public statement. Even after that, they are not completely sure about results. And here goes John Smith, who indirectly claims, that he knows how OSM newbies think and so on, when he refers to them. No, he knows almost nothing.

There are only a few statistical studies, showing basically only one thing: spread of amount of edits (statistical or geographical). But there is no studies of behavior. I completely understand, that it’s really hard to conduct a study like that, I don’t even claim that I know how to do that. But what I’m trying to say, is that referring to newbies does not make much sense without it. Intuitive “knowledge” is not a knowledge at all.

Indeed, some people (only a few of OSM contributors, actually) have certain experience with newbies because they organized mapping parties or workshops. But is that empirical knowledge universal? Most likely, no.

For example, HOT volunteers have different motivation from people, who want to improve/fix map for their navigation device.Those who want to “help everybody at any cost” (importers of illegal data) have completely different motivation too. Lack of skill of reading in English or German also changes the situation, and if combined with overestimation of this skill, makes a disaster for translations.

… See full entry

С одной стороны, не хочу давать рецепт тем, кто до этого еще не додумался, с другой - принцип такой ситуации должен быть описан, как негативный случай, который может повторяться.

---

Представьте себе, что вы - отъявленный анархист, придумали тег для какой-то своей задачи или просто потому что захотелось, чтобы он был.

Представьте, что по какой-то причине вы не хотите проводить его через процедуру proposal-а, или подозреваете, что его не примут, потому что тег откровенно невнятный (или совсем дрянной). Как поступить, чтобы “протолкнуть” этот тег к использованию, создать у других ничего не подозревающих участников впечатление, что он правильный и нужный? Очень просто.

Если вы придумали только новое значение (value) - все вообще элементарно. Дописываете его на страницу тега ко всем остальным. Ни в коем случае не создавайте страницу тега (которая RU:Tag:key=value для вашего значения). Потому что там надо будет, как полагается, писать, что тег не одобрен сообществом, но используется. И вообще, пытаться как-то его объяснить (что не всем доступно - многие одними только картинками объясняются). Voilà - ваш сомнительный тег смешан с ранее принятыми на странице ключа. На странице красуется зеленая метка “Одобрен сообществом”, относящаяся, автоматически, ко всему содержимому.

Если вы придумали целый ключ со значениями, то все только немного сложнее.

Ищете в Wiki все смежные по смыслу теги, ключи, значения. Например, если он у вас имеет отношение к растительности - всё, что касается растительности. Самое ценное - найти большие списки обозначений вроде страницы Map Features.

Добавляете упоминания своего тега туда. В секции типа См. также:, Дополнительные теги, и, конечно, в сводные таблицы. Не забудьте добавить несколько предложений описания.

Также не вздумайте создавать страницы для ключа (вида RU:Key:ваш_бред) и тегов (вида RU:Tag:ваш_бред=другой_бред) на его основе, по той же причине - там придется честно признаться, что вы его сочинили от балды.

---

… See full entry

OSM project is famous for its quality assessment tools. We have tools to track changesets, to check properties of objects against certain reference databases, we have Achavi to visualize changesets, we have KeepRight to analyze geometry, check website links and to do lots of things. There is also a mechanism of notes, which works as an issue tracker for both bugs and “feature requests”. Ability to comment on changesets is nice, but it’s a kind of limited: only author of changeset gets a notification and there is no way to bind a comment to an object to turn it into another issue tracking tool. But all these tools are for data: geometry and properties (tags).

Infrastructural elements of OSM, such rendering styles, websites, editors, being an opensource sub-projects, usually have issue trackers on GitHub.

But there is absolutely nothing for tagging schemes. I mean, yes, you can write something on Discussion page of Wiki, or complain somewhere on mailing lists or forum. But nobody is checking discussion pages constantly, while posts on mail lists and forums have a tendency to be buried pretty quickly by other stuff posted there.

For me, it seems to be logical to have some place, where everyone can tell about an issue of tagging scheme:

• uncertainty,
• contradiction,
• overlapping meaning,
• linguistic issues (different meaning of word, used for key or value in different cultures),
• systematic misuse of tags,
• lack of way to tag particular entity.

Definitely, it should not be a place to ask questions about tagging - it should be a place exclusively for reporting issues and requesting features, just like the most of issue trackers.

… See full entry

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.

… See full entry

Основополагающий принцип внесения данных в OSM - Truth on the ground, то есть внесение информации только о фактическом состояние местности. Второй основополагающий принцип - верифицируемость, то есть любые внесенные данные должны быть таковы, что их может независимо подтвердить любой другой человек. Дополнением к этим принципам является возможность внесения нематериальных фактических свойств объектов: административных границ, форм собственности, прав доступа на территорию, времени работы учреждений - всего, что закреплено законами, правилами, уставами и так далее.

В общем случае, эти правила просты для понимания и применения. Однако, некоторые случаи требуют знания того, какой именно факт отражает то или иное свойство (тег). Например, часто у начинающих участников проекта возникают проблемы с использованием градаций важности в дорожной сети: вместо факта важности дороги (что она соединяет, какую роль играет в дорожном графе) они пытаются скопировать классы дорог по строительной классификации. Это неверно, потому что значения ключа highway= не предназначены для отражения строительной классификации. Для отражения физических свойств предназначены теги surface=, width=, lanes=, smoothness=.

Таким образом, вопрос вида: “Обозначаем ли мы конкретно этот объект по назначению или по фактическому использованию?” - не имеет смысла. Все обозначается в соответствии с тем, какой именно факт должен отражать тот или иной тег.

К большому сожалению, не все теги достаточно четко документированы, но к этому нужно стремиться, а вопросы относительно того или иного тега, в случае неясности, стоит задавать именно в ключе того, какой же факт отражает этот тег.

Некоторое время назад на официальном портале “открытых” данных data.mos.ru был опубликован набор данных “Адресный реестр зданий и сооружений города Москвы”. Также было получено подтверждение разрешения на использование этих данных в OpenStreetMap. Давайте же посмотрим, что из себя представляют эти данные, на что они годятся.

Для начала, собственно формат. Это JSON. Не GeoJSON. То есть он не годится для непосредственной загрузки в ГИС или любой софт, работающий с GeoJSON. Для того, чтобы его к этому подготовить, нужно изрядо повозиться.

Если геометрия объекта - multipolygon (имеет отверстия и т.п.), хранится она тоже криво. Сами товарищи из Департамента информационных технологий не осилили это поддержать, потому на карте все показывается в виде полигонов, без отверстий.

Теперь к самой геометрии. Волей случая (на каком-то пиратском сайте) мне попался набор данных, подготовленный в Autocad, называвшийся “Топосъемка Москвы” и датированный концом девяностых годов, то есть это то, что сняли первый раз после развала СССР. Данные были в системе координат МГГТ, там содержалось все - дороги, здания, газоны, уличные фонари. Так вот, около 90% геометрии в этом новом адресном реестре полностью оттуда. Качество перепроецирования в WGS84 - достойное.

У геометрии есть свои особенности. Многие здания обведены по footprint-у, то есть по уровню земли. В итоге, в контур попадает подъезд, но не его козырек, а выдающаяся наружу часть здания. У некоторых обведена проекция. Тогда в контур попадает козырек. То же может касаться всяких боковых входов в подвал или даже подвальных помещений, которые выходят за пределы контура наземной части.

… See full entry

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

… See full entry

Definitely, I’m not the oldest and the most experienced member of the OSM community. But for the last five years I had quite a few discussions and arguments regarding of basic principles of contributing to OSM. Usually, it’s about the nature of those basic rules, listed on Good practice Wiki page. (By the way, having the majority of “don’ts” there, shouldn’t it be called “Bad practice”?) Discussions I’m talking about took place on Russian OSM community forum, in comments on several online articles (written by me) about OSM and in a real life.

People, especially those, who have no familiarity with geospatial science, database architecture, IT in general, just can’t get the idea, why these rules are so important and where they come from. Common misconception also includes association of OSM project with certain derivative product: interactive web map on openstreetmap.org or converted maps for digital navigation systems (OsmAnd, Garmin, Navitel and so on).

These people, including several experienced contributors, wonder: “Why shouldn’t we tag it in a manner to make it visible on a map? There is no use in this object if it’s not displayed (searchable).” Their understanding is based on particular way to use data: visually observe a map, run search on indexable objects on their navigation device/software and so on.

Is there any way to explain, why they must not do what they do without mentioning that OSM is a database? Honesty, I don’t know any reliable one. And why should anyone look for one, if the concept of structured geospatial database as both core component and product of OSM project explains more or less every well-known basic rule?

Someone could probably say, that it’s a question of philosophy or even demagogic thing to insist on “OSM is a database” instead of “OSM is a map”. But here are several reasons to do so:

… See full entry

Despite its name, OpenStreetMap is a database in a first place. And openstreetmap.org provides more or less informative page for each object in contains - way, node or relation. For example, look at this way: osm.org/way/80476600 - it’s the Millennium Oakwood park, located at the Isle of Man.

Nowadays, if someone wants to find something on the Web, the most obvious way to do that is to use a web search. Such as Google, for example.

Let’s search for “Millennium Oakwood”. Google Maps widget goes first, couple of government sites following it, someone’s photo on Flickr and tons of rubbish.

Let’s do it more straightforward: “Millennium Oakwood OpenStreetMap”. No Google Maps, but other results are quite similar. One exception - couple of entries from triposo.com, which uses OpenStreetMap.

So, basically, there is no way to find an object in OSM database via web search updated: for general public, who have no intention to query OSM data specifically.

Non-searchable = non-existent, at least, for people, using text search on the web.

I can imagine, that someone can argue, that OSM shouldn’t display its “guts” - lists of nodes, links to changesets and so on. But actually, many of these pages somehow were indexed by search engines and you can find at least a fraction of them.

I don’t know, if current rules of robots.txt file (which tells search engines what not to index) are actually preventing it, or there is another reason for it. But currently, the whole bunch of information in OSM database is just completely hidden from public searches.

For me, it seems like talking about informing people of OSM and hiding it from them in the same time is a kind of self-contradiction.

OpenStreetMap has many tags, inherited from a natural language with blurred meaning and definitions, depending on each mapper’s understanding of associated natural language term. Also, many tags are representing more than one property of an object, such as, say, type of flora, populating particular area and presence of management of this area. (Good example is natural=grassland and landuse=grass.)

In an ideal case, any classification system should have only “atomic” properties instead of “molecular”, where several real properties are linked. (Good example is the recently introduced scheme with leaf_type= and leaf_cycle= - independent properties instead of linked ones.)

One of the extremely widespread tags with both bad features is natural=wood.

It belongs to natural=* class, and it gives people an idea, that only natural habitats should be tagged with it. Therefore, we also have landuse=forest, which means the same kind of habitat, but more related to man-made objects.

Actually, it creates the really huge problem. First, let’s try to explain what exactly we should map with it.

Both natural wood and any kind of planted forest are areas of vegetation, dominated by trees. But there is no clear definition (in OSM), what does “dominated” mean.

natural=wood should, supposedly, tells us, that area of vegetation forms “natural habitat”. But there is no clear explanation, what does “natural” mean.

landuse=forest should, supposedly, tell us, that area of vegetation is managed, or planted, or forms artificial habitat, or trees there are non-native. There is no clear explanation, is there any difference between landuse=forest and landuse=plant_nursery - difference is only implied, because nursery should be only used to plant young trees for sale or for planting it somewhere else for forestry management purpose.

So many variants, so many assumptions and lots of guessing.

… See full entry