Те, кто хоть немного знаком с проектом OpenStreetMap, вероятно, слышали о паре принципов, которые заложены в его основу: «any tags you like» и тот факт, что первично в этом проекте наполнение картографической базы данных, а не то, как содержимое этой базы отображает стиль Standard на osm.org. Но так ли все хорошо и радужно с семантической структурой этой базы данных, учитывая первый принцип? Читая русскоязычную ветку форума OSM, я решил разобраться в ситуации и описать ее здесь.
Еще немного истории и фактов. Проект OSM зародился в Великобритании. Потому основным языком для тегов, которые в большинстве случаев являются просто словами, является британский английский. Потому обозначения спортивного центра или территории, которую называют «окру́га», пишутся как
Традиционно, теги состоят из ключа (key — то, что слева от знака равенства) и значения (value — то, что справа). Это как бы указывает на принцип того, что ключ соответствует классу объектов или свойств, а значение — объекту или конкретной величине (value) свойства. Иногда в ключах и значениях используется синтаксис пространства имен. Чаще это делается в тех случаях, когда несколько тегов составляют так называемую схему обозначений, где общее обозначение объекта дополняется специфичными для него свойствами. Например:
Такая пара тегов будет означать «социальное учреждение, место дневного пребывания, для престарелых». Этот вариант довольно совершенен, потому что в пространстве имен, названном по имени корневого ключа, может быть сколько угодно других ключей, соответствующих уточняющим свойствам.
Другой распространенный метод — это уточняющие теги без использования пространства имен. Например:
Это значит: «искусственное препятствие, столб, убираемый». С точки зрения естественного языка, «столб=убираемый» — довольно бредовая конструкция, но надо обязательно иметь в виду, что в OSM все эти слова соответствуют абстракциям, которые должны быть, в идеале, четко описаны в Wiki проекта (что случается не всегда). Минус такого подхода в том, что такой специфический только для столба-препятствия уточняющий тег может быть только один, так как в OSM нельзя назначить объекту два тега с одним ключом. Неспецифических уточняющих тегов, применяемых и для других объектов, может быть при этом сколько угодно — скажем, у этого столба может быть обозначен материал и высота:
Пока все кажется достаточно логичным и понятным. Но, как известно, любую хорошую вещь достаточно легко испортить. Очевидно, что для того, чтобы хранить какие-то данные в базе, сохраняя возможность просто их разбирать, выделять подмножества по нужным признакам, находить вполне конкретные данные и объекты, база должна сохранять более или менее стройную семантику данных. Иначе она превращается в слабо структурированный текст. Но вспомним, что база OSM, являясь картографической базой, обязана хранить информацию о реальном мире, который многие воспринимают «как есть», в виде неделимых объектов, не выделяя у них заранее никаких особых свойств. Люди просто привыкли говорить о том, что видят. Обычно, когда речь идет о крупных проектах с большими базами объектов, например — интернет-магазинах, типичный сценарий использования таких баз — это выборка данных для пользователя. В каких-то случаях это параметрический поиск, в других — «умный» поиск, который позволяет ассоциировать наборы свойств объектов (товаров) с поисковыми запросами в свободной форме.
Ситуация в OSM — обратная: участники проекта, наоборот, вносят данные в базу, при этом каждый делает это в меру своих навыков, в том числе — способностей к выделению главных черт объектов. А учитывая принцип «any tags you like», который призван гарантировать расширяемость системы обозначений и способность проекта хранить самые разные данные для самых разных нужд, иногда такое вот использование привычного естественного языка ведет если не к катастрофическим для семантики результатам, то к чему-то, что достойно эпитета «крайняя неопределенность».
Подумайте и честно ответьте себе: если вы хотите купить какой-то конкретный товар, вы будете искать магазин, где такой товар обязательно должен быть, или где он может оказаться только с какой-то сравнительно небольшой вероятностью? Желающих тратить время на беготню по местам, где искомое может оказаться только волей случая, скорее всего, найдется мало. Но представьте себе, в OSM есть теги, обозначающие магазин, где неизвестно что продается. Например, это
Фактически, этот тег просто перекочевал в схему обозначения из естественного языка. «Спасибо» за него можно сказать человеку, которого зовут Etric Celine. Как видите, на своей странице в Wiki проекта он вполне честно пишет, что ему плевать на обсуждения обозначений (формальную процедуру предложения тегов и обсуждения его перед принятием), на какой-либо порядок, зато он считает очень важным, чтобы каждый «делал хоть что-нибудь». Вот он и сделал нечто: ввел в использование тег, который практически ничего не значит. Знаете, сколько таких «магазинов неизвестно чего» в базе OSM? Без малого — пятьдесят тысяч. И множество людей, только став участниками проекта и не разобравшись в важности того, чтобы описывать свойства объектов, вешают этот тег на любой попавшийся маленький торговый павильон, если не знают лучшего обозначения для него, хотя таковые существуют и для табачных магазинов, и для мест, где продают газеты, и для мест, где продают мороженое, а также многих других. Что руководит ими? То, что они не понимают важности структурированности информации в базе, зато хорошо знают, что привыкли называть такие заведения «киосками».
Для опытного разработчика или архитектора баз данных ситуация, когда дополнительно к многочисленным обозначениям типа «супермаркет», «киоск», «молл», не существует никакого универсального средства описания ассортимента, может показаться предельно странной, но такова реальность. То есть конечно, есть теги для книжных магазинов, или магазинов «сделай сам». Но вот что продает супермаркет или универсам — не описать никак, при всем желании. О том, какова разница между супермаркетом и моллом, к слову, тоже идут длительные споры, потому что провести четкую границу — невозможно: хотя молл и является, по определению, «зданием, вмещающим множество магазинов, развлекательных заведений, кафе и ресторанов», но ведь супермаркет тоже может иметь внутри помещения для арендаторов. Так когда супермаркет превращается в молл, а главное — важно ли это различие вообще?
Очень многие распространенные теги имеют не очень четкие определения и границы применимости. Например, невозможно сформулировать четкую разницу также и между рестораном и кафе. Такая разница — это не размер, не обслуживание официантами, не ассортимент блюд, не время работы, не способ посадки посетителей, не требование бронирования столика, не цены, и не что-либо еще. Это просто слова «кафе» и «ресторан». Конечно, в некоторых предельных случаях слово «кафе», определенно, плохо подходит к каким-то местам очень высокого класса. Но где четкая граница? Ее не существует. Потому назначение тегов
Иногда попытки классификации делаются, но естественный язык и повседневные знания мешают создать правильную, корректную классификацию. Чуть ли не с самого основания проекта OSM, для уточнения типа деревьев в лесах существовали два тега:
Еще одна ситуация, когда знания в предметной области у авторов тегов были недостаточно строгими, что породило невнятные и противоречивые описания, это случай с башнями и мачтами, относящимися в OSM к значениям ключа рукотворных объектов
Наиболее курьезны (и, в случае распространения такой практики — неприятны из-за семантической дивергенции, то есть расхождения смыслов обозначений) ситуации — это использование в тегах таких слов, которые в разных языках имеют совершенно разное значение. Недавний пример — это предложение одного из русскоязычных участников ввести тег, обозначающий место, где можно получить «бизнес-ланч». Курьезность этой ситуации в том, что, вероятно, только в России словом «бизнес-ланч» (придумали это где-то в девяностые годы прошлого века, когда все, имеющее приставку «бизнес-» звучало солиднее) называют набор блюд по фиксированной цене, который можно получить в определенное время дня. В остальном мире, это называется французским table d'hôte, fix-price или другим местным словом, однако business lunch, в любом случае, означает что-то, что связано с переговорами за обедом, а не какой-то определенный тип обслуживания в ресторане. Конечно, слова, которые используются в тегах, условны. Но они должны быть понятны остальным участникам проекта, по крайней мере, до такой степени, чтобы не было сомнений, к какой предметной области относится данный тег. Потому принятие таких обозначений, которые будут вводить в заблуждение любого владеющего английским, родом не из России, недопустимо.
Обратная ситуация встречается еще чаще. Заимствованные слова редко когда совсем не меняют своего смысла, а потому те, для кого культура англоязычных стран — темный лес, частенько совершают ошибки, трактуя теги в соответствии со смыслом созвучного заимствованного слова, а не с тем, что это слово значит в оригинале. Также, созвучные слова могут существовать в разных языках независимо. Так, русскоязычных участников проекта OSM часто вводит в заблуждение тег
Даже среди англоязычного сообщества самого по себе согласие есть не всегда, из-за культурных различий. Например, типичный американский drugstore кроме лекарств, продает кучу промышленных товаров, косметику, еду и напитки. А рецептурный отдел может быть, неожиданно, и в супермаркете. Британцы же имеют представление об аптеке, несколько более близкое к привычному жителям России.
Другой пример — это использование таких слов, как cabin, hut, как значений ключа
Безусловно, семантический хаос, происходящий из естественного языка, не господствует в проекте, хотя и довольно заметен. Есть довольно сильные и успешные прецеденты попыток создания надежных, непротиворечивых и четких классификаций, заменяющих теги со смутным значением на наборы ключей, отвечающих каждый за свое отдельное свойство. Одна из таких, достаточно известных, но официально не одобренных еще схем — это Healthcare 2.0. Она создана с целью, чтобы иметь инструменты, описывающие медицинские учреждения самого разного типа без неопределенностей, присущих, например, тегу
Новые схемы, которые хорошо продуманы, оказываются практически независимыми от культурного и языкового контекста. Максимум, что может потребоваться — добавление одного-двух значений какого-то ключа. Например, Healthcare 2.0 позволяет описать специфические для России медицинские учреждения вроде фельдшерского пункта, хотя ее авторы не имели о таком учреждении никакого понятия. В этом — сила использования элементарных свойств, которые можно свободно комбинировать.
Самое печальное в этой ситуации, как мне кажется, то, что даже многие опытные участники проекта не понимают этой проблемы или понимают ее, но утверждают, что она незначительна, или что ее решение может существенно увеличить порог вхождения и отпугнуть пресловутых новичков (о которых многие очень любят рассуждать, приписывая им удобные для аргументации своей точки зрения качества).
Практика же показывает, что во-первых, при появлении новой, более определенной схемы, люди успешно начинают ею пользоваться, получив возможность обозначить то, что раньше было обозначить нельзя или неудобно, но хотелось. Во-вторых, OSM существует для того, чтобы создать максимально адекватную реальности, максимально полную и при этом свободную в использовании карту мира, а не для того, чтобы создать клуб по интересам (хотя это тоже неплохо). И если кому-то сложно понять принцип вполне очевидных обозначений, но легко бездумно использовать невнятные, то какой вклад в создание качественных данных он может внести? И наоборот, люди, которые недовольны качеством схем обозначения или отсутствием каких-то обозначений, вполне могут внести свой полезный вклад, если такие адекватные способы появятся.
Еще немного истории и фактов. Проект OSM зародился в Великобритании. Потому основным языком для тегов, которые в большинстве случаев являются просто словами, является британский английский. Потому обозначения спортивного центра или территории, которую называют «окру́га», пишутся как
leisure=sports_centre и place=neighbourhood соответственно. Употребляются и немецкие слова, например, одним из (нерекомендуемых к употреблению) обозначений типов мегалитических сооружений является тег megalith_type=grosssteingrab от немецкого Großsteingrab (дольмен). Традиционно, теги состоят из ключа (key — то, что слева от знака равенства) и значения (value — то, что справа). Это как бы указывает на принцип того, что ключ соответствует классу объектов или свойств, а значение — объекту или конкретной величине (value) свойства. Иногда в ключах и значениях используется синтаксис пространства имен. Чаще это делается в тех случаях, когда несколько тегов составляют так называемую схему обозначений, где общее обозначение объекта дополняется специфичными для него свойствами. Например:
social_facility=day_caresocial_facility:for=seniorТакая пара тегов будет означать «социальное учреждение, место дневного пребывания, для престарелых». Этот вариант довольно совершенен, потому что в пространстве имен, названном по имени корневого ключа, может быть сколько угодно других ключей, соответствующих уточняющим свойствам.
Другой распространенный метод — это уточняющие теги без использования пространства имен. Например:
barrier=bollardbollard=removableЭто значит: «искусственное препятствие, столб, убираемый». С точки зрения естественного языка, «столб=убираемый» — довольно бредовая конструкция, но надо обязательно иметь в виду, что в OSM все эти слова соответствуют абстракциям, которые должны быть, в идеале, четко описаны в Wiki проекта (что случается не всегда). Минус такого подхода в том, что такой специфический только для столба-препятствия уточняющий тег может быть только один, так как в OSM нельзя назначить объекту два тега с одним ключом. Неспецифических уточняющих тегов, применяемых и для других объектов, может быть при этом сколько угодно — скажем, у этого столба может быть обозначен материал и высота:
material=concrete, height=0.7.Пока все кажется достаточно логичным и понятным. Но, как известно, любую хорошую вещь достаточно легко испортить. Очевидно, что для того, чтобы хранить какие-то данные в базе, сохраняя возможность просто их разбирать, выделять подмножества по нужным признакам, находить вполне конкретные данные и объекты, база должна сохранять более или менее стройную семантику данных. Иначе она превращается в слабо структурированный текст. Но вспомним, что база OSM, являясь картографической базой, обязана хранить информацию о реальном мире, который многие воспринимают «как есть», в виде неделимых объектов, не выделяя у них заранее никаких особых свойств. Люди просто привыкли говорить о том, что видят. Обычно, когда речь идет о крупных проектах с большими базами объектов, например — интернет-магазинах, типичный сценарий использования таких баз — это выборка данных для пользователя. В каких-то случаях это параметрический поиск, в других — «умный» поиск, который позволяет ассоциировать наборы свойств объектов (товаров) с поисковыми запросами в свободной форме.
Ситуация в OSM — обратная: участники проекта, наоборот, вносят данные в базу, при этом каждый делает это в меру своих навыков, в том числе — способностей к выделению главных черт объектов. А учитывая принцип «any tags you like», который призван гарантировать расширяемость системы обозначений и способность проекта хранить самые разные данные для самых разных нужд, иногда такое вот использование привычного естественного языка ведет если не к катастрофическим для семантики результатам, то к чему-то, что достойно эпитета «крайняя неопределенность».
Подумайте и честно ответьте себе: если вы хотите купить какой-то конкретный товар, вы будете искать магазин, где такой товар обязательно должен быть, или где он может оказаться только с какой-то сравнительно небольшой вероятностью? Желающих тратить время на беготню по местам, где искомое может оказаться только волей случая, скорее всего, найдется мало. Но представьте себе, в OSM есть теги, обозначающие магазин, где неизвестно что продается. Например, это
shop=kiosk. Как видно из описания, там можно обнаружить что угодно, от сигарет до газет. А можно и не обнаружить. Единственная четкая характеристика такого магазина — это его размер. Потому что нельзя даже точно сказать, является ли киоск маленьким торговым павильоном, стоящим отдельно, или он встроен в какое-то здание. А в некоторых странах словом kiosk могут называть просто маленький магазин. Фактически, этот тег просто перекочевал в схему обозначения из естественного языка. «Спасибо» за него можно сказать человеку, которого зовут Etric Celine. Как видите, на своей странице в Wiki проекта он вполне честно пишет, что ему плевать на обсуждения обозначений (формальную процедуру предложения тегов и обсуждения его перед принятием), на какой-либо порядок, зато он считает очень важным, чтобы каждый «делал хоть что-нибудь». Вот он и сделал нечто: ввел в использование тег, который практически ничего не значит. Знаете, сколько таких «магазинов неизвестно чего» в базе OSM? Без малого — пятьдесят тысяч. И множество людей, только став участниками проекта и не разобравшись в важности того, чтобы описывать свойства объектов, вешают этот тег на любой попавшийся маленький торговый павильон, если не знают лучшего обозначения для него, хотя таковые существуют и для табачных магазинов, и для мест, где продают газеты, и для мест, где продают мороженое, а также многих других. Что руководит ими? То, что они не понимают важности структурированности информации в базе, зато хорошо знают, что привыкли называть такие заведения «киосками».
Для опытного разработчика или архитектора баз данных ситуация, когда дополнительно к многочисленным обозначениям типа «супермаркет», «киоск», «молл», не существует никакого универсального средства описания ассортимента, может показаться предельно странной, но такова реальность. То есть конечно, есть теги для книжных магазинов, или магазинов «сделай сам». Но вот что продает супермаркет или универсам — не описать никак, при всем желании. О том, какова разница между супермаркетом и моллом, к слову, тоже идут длительные споры, потому что провести четкую границу — невозможно: хотя молл и является, по определению, «зданием, вмещающим множество магазинов, развлекательных заведений, кафе и ресторанов», но ведь супермаркет тоже может иметь внутри помещения для арендаторов. Так когда супермаркет превращается в молл, а главное — важно ли это различие вообще?
Очень многие распространенные теги имеют не очень четкие определения и границы применимости. Например, невозможно сформулировать четкую разницу также и между рестораном и кафе. Такая разница — это не размер, не обслуживание официантами, не ассортимент блюд, не время работы, не способ посадки посетителей, не требование бронирования столика, не цены, и не что-либо еще. Это просто слова «кафе» и «ресторан». Конечно, в некоторых предельных случаях слово «кафе», определенно, плохо подходит к каким-то местам очень высокого класса. Но где четкая граница? Ее не существует. Потому назначение тегов
amenity=cafe и amenity=restarurant — нечеткая процедура, которая, строго говоря, противоречит еще одному важному принципу OSM: верифицируемости. Этот принцип гласит, что любое обозначение, внесенное в базу, должно быть таким, что другой участник проекта мог бы его подтвердить, то есть однозначно обозначить тем же самым образом. Наличие в названии места слова «ресторан» — не критерий, потому что это в русском языке есть заимствованные «кафе» и «ресторан». А как быть с чешским hospoda или польским tawerna? А никак, потому что идти всегда по пути «к каждому слову (понятию языка) должен быть свой тег» — неверно. Используя абстракцию, как мыслительный инструмент, нужно находить сходные и различные свойства объектов, а потом обозначать именно эти свойства, не обращая внимания на привычку. Тогда предоставить пользователю карты или справочника на основе данных OSM действительно полезную информацию будет проще: ему не нужно будет гадать, что же имел в виду тот, кто обозначил на карте нечто, как ресторан, а не как кафе. Параметрический поиск или демонстрация нужных свойств в списке — определенно более дружественное пользователю решение, чем подсовывание ему вообще всех мест, где можно поесть, почти без всяких пояснений.Иногда попытки классификации делаются, но естественный язык и повседневные знания мешают создать правильную, корректную классификацию. Чуть ли не с самого основания проекта OSM, для уточнения типа деревьев в лесах существовали два тега:
wood=coniferous, wood=deciduous (дословно — «деревья с шишками» и «листопадные деревья»). Эти два слова — coniferous, deciduous — в английском языке являются обиходными. И люди привыкли противопоставлять их. По-русски в таких случаях говорят хвойные и лиственные, что несколько правильнее с точки зрения биологии, но тоже не до конца. На самом деле, существуют деревья, которые сезонно сбрасывают листву, и те, которые этого не делают (вечнозеленые). И в то же время, существуют деревья с листьями и деревья с иголками. То есть может быть дерево с иголками и шишками, но сбрасывающее иголки на зиму (Лиственница европейская). Или дерево с листьями, но вечнозеленое (Лавровишня). Плюс, есть еще другие, менее многочисленные свойства. Не так давно, первоначальная схема была заменена на схему с двумя ключами, отвечающими за сезонный цикл листьев и их форму. Еще одна ситуация, когда знания в предметной области у авторов тегов были недостаточно строгими, что породило невнятные и противоречивые описания, это случай с башнями и мачтами, относящимися в OSM к значениям ключа рукотворных объектов
man_made=*. В строительной инженерии — области знаний, перекрывающей все типы рукотворных стационарных конструкций, башнями называют такие узкие вертикальные конструкции, которые стоят только благодаря опоре на собственный фундамент. А мачтами — то, что имеет оттяжки, каждая из которых крепится к анкерному устройству. То есть все довольно просто, к тому же — такая классификация носит международный характер. Но в других технических областях эти термины могут использоваться иначе. Скажем, мачтами освещения энергетики называют и то, что с точки зрения строителя — башня. Итог — в OSM эти теги присваиваются рукотворным объектам достаточно вольно. Наиболее курьезны (и, в случае распространения такой практики — неприятны из-за семантической дивергенции, то есть расхождения смыслов обозначений) ситуации — это использование в тегах таких слов, которые в разных языках имеют совершенно разное значение. Недавний пример — это предложение одного из русскоязычных участников ввести тег, обозначающий место, где можно получить «бизнес-ланч». Курьезность этой ситуации в том, что, вероятно, только в России словом «бизнес-ланч» (придумали это где-то в девяностые годы прошлого века, когда все, имеющее приставку «бизнес-» звучало солиднее) называют набор блюд по фиксированной цене, который можно получить в определенное время дня. В остальном мире, это называется французским table d'hôte, fix-price или другим местным словом, однако business lunch, в любом случае, означает что-то, что связано с переговорами за обедом, а не какой-то определенный тип обслуживания в ресторане. Конечно, слова, которые используются в тегах, условны. Но они должны быть понятны остальным участникам проекта, по крайней мере, до такой степени, чтобы не было сомнений, к какой предметной области относится данный тег. Потому принятие таких обозначений, которые будут вводить в заблуждение любого владеющего английским, родом не из России, недопустимо.
Обратная ситуация встречается еще чаще. Заимствованные слова редко когда совсем не меняют своего смысла, а потому те, для кого культура англоязычных стран — темный лес, частенько совершают ошибки, трактуя теги в соответствии со смыслом созвучного заимствованного слова, а не с тем, что это слово значит в оригинале. Также, созвучные слова могут существовать в разных языках независимо. Так, русскоязычных участников проекта OSM часто вводит в заблуждение тег
highway=alley. Дело в том, что английское слово alley звучит похоже на французское allée и русское аллея. Русское было заимствовано из французского, а потому обозначает похожее: дорогу для прогулок, вдоль которой посажены деревья. Английское же alley — это, обычно, узкий технический проезд или проход вдоль боковой или задней стены зданий, либо проход между частными земельными участками, расположенными в один или два ряда. Это слово ближе к русскому «задворки». Но неопытные участники часто пытаются обозначить тегом highway=alley именно аллею с деревьями.Даже среди англоязычного сообщества самого по себе согласие есть не всегда, из-за культурных различий. Например, типичный американский drugstore кроме лекарств, продает кучу промышленных товаров, косметику, еду и напитки. А рецептурный отдел может быть, неожиданно, и в супермаркете. Британцы же имеют представление об аптеке, несколько более близкое к привычному жителям России.
Другой пример — это использование таких слов, как cabin, hut, как значений ключа
building=*. В соответствии с ключом, эти теги должны обозначать тип здания. Однако четкой разницы между ними не существует. Зато есть ассоциации с назначением. Скажем, американец, вероятнее всего, будет ассоциировать cabin с чем-то вроде дачи, то есть с маленьким частным или сдаваемым в аренду домиком для отдыха на природе. А житель Норвегии, видя слово hut, возможно, вспомнит о горных зимовьях, принадлежащих туристической ассоциации Den Norske Turistforening, которыми имеют право пользоваться ее члены. Аналогичная ассоциация может возникнуть у говорящего по-немецки швейцарца, только уже с горными приютами Schweizer Alpen Club. То есть люди вполне могут компенсировать отсутствие четкого определения, касающегося типа здания, ассоциацией с его назначением. А в России до недавнего времени этими тегами могли обозначать избу, что неверно, потому что ее и так можно обозначить, как «здание, построенное из бревен», используя теги building=yes, material=log. Безусловно, семантический хаос, происходящий из естественного языка, не господствует в проекте, хотя и довольно заметен. Есть довольно сильные и успешные прецеденты попыток создания надежных, непротиворечивых и четких классификаций, заменяющих теги со смутным значением на наборы ключей, отвечающих каждый за свое отдельное свойство. Одна из таких, достаточно известных, но официально не одобренных еще схем — это Healthcare 2.0. Она создана с целью, чтобы иметь инструменты, описывающие медицинские учреждения самого разного типа без неопределенностей, присущих, например, тегу
amenity=doctors. Используя ее, можно описать как большой стационар, так и кабинет врача частной практики. Довольно большая работа по созданию схемы для обозначения состояния лесов проделана одним из российских участников проекта. К большому сожалению, дальше размещения описания на странице устаревших на данный момент тегов дело не пошло. Новые схемы, которые хорошо продуманы, оказываются практически независимыми от культурного и языкового контекста. Максимум, что может потребоваться — добавление одного-двух значений какого-то ключа. Например, Healthcare 2.0 позволяет описать специфические для России медицинские учреждения вроде фельдшерского пункта, хотя ее авторы не имели о таком учреждении никакого понятия. В этом — сила использования элементарных свойств, которые можно свободно комбинировать.
Самое печальное в этой ситуации, как мне кажется, то, что даже многие опытные участники проекта не понимают этой проблемы или понимают ее, но утверждают, что она незначительна, или что ее решение может существенно увеличить порог вхождения и отпугнуть пресловутых новичков (о которых многие очень любят рассуждать, приписывая им удобные для аргументации своей точки зрения качества).
Практика же показывает, что во-первых, при появлении новой, более определенной схемы, люди успешно начинают ею пользоваться, получив возможность обозначить то, что раньше было обозначить нельзя или неудобно, но хотелось. Во-вторых, OSM существует для того, чтобы создать максимально адекватную реальности, максимально полную и при этом свободную в использовании карту мира, а не для того, чтобы создать клуб по интересам (хотя это тоже неплохо). И если кому-то сложно понять принцип вполне очевидных обозначений, но легко бездумно использовать невнятные, то какой вклад в создание качественных данных он может внести? И наоборот, люди, которые недовольны качеством схем обозначения или отсутствием каких-то обозначений, вполне могут внести свой полезный вклад, если такие адекватные способы появятся.
