Еще немного истории и фактов. Проект 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'hote, fix-price или другим местным словом, однако business lunch, в любом случае, означает что-то, что связано с переговорами за обедом, а не какой-то определенный тип обслуживания в ресторане. Конечно, слова, которые используются в тегах, условны. Но они должны быть понятны остальным участникам проекта, по крайней мере, до такой степени, чтобы не было сомнений, к какой предметной области относится данный тег. Потому принятие таких обозначений, которые будут вводить в заблуждение любого владеющего английским, родом не из России, недопустимо.
Обратная ситуация встречается еще чаще. Заимствованные слова редко когда совсем не меняют своего смысла, а потому те, для кого культура англоязычных стран — темный лес, частенько совершают ошибки, трактуя теги в соответствии со смыслом созвучного заимствованного слова, а не с тем, что это слово значит в оригинале. Также, созвучные слова могут существовать в разных языках независимо. Так, русскоязычных участников проекта OSM часто вводит в заблуждение тег
highway=alley. Дело в том, что английское слово alley звучит похоже на французское allee и русское аллея. Русское было заимствовано из французского, а потому обозначает похожее: дорогу для прогулок, вдоль которой посажены деревья. Английское же 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 существует для того, чтобы создать максимально адекватную реальности, максимально полную и при этом свободную в использовании карту мира, а не для того, чтобы создать клуб по интересам (хотя это тоже неплохо). И если кому-то сложно понять принцип вполне очевидных обозначений, но легко бездумно использовать невнятные, то какой вклад в создание качественных данных он может внести? И наоборот, люди, которые недовольны качеством схем обозначения или отсутствием каких-то обозначений, вполне могут внести свой полезный вклад, если такие адекватные способы появятся.
Комментарии (42)
sapper
29.10.2015 11:35+1Ода из очень больших странностей, по моему мнению — нет договоренности, как правильно проставить одному зданию два адреса(такая адресация есть почти у каждого углового дома в России).
putnik
29.10.2015 16:17+3Ну, не то, чтобы совсем нет договорённости. Но способов, как это можно обозначить, действительно штук пять.
FractalizeR
29.10.2015 17:05На домах ведь таблички есть с официальным адресом. Неужели их две разных? Никогда не обращал внимания, наверное.
shoorick
29.10.2015 21:05Полно?. Буквально соседний дом имеет два адреса. Я 10 лет проучился в школе с двумя адресами. В центре города, где живу, наверное, в каждом квартале найдётся такой дом.
FSA
29.10.2015 21:53Может быть просто у вас в городе таких домов нет. Я у себя из всего того, что обошёл видел только 2 таких дома. Раньше были два маленьких домика, потом иснесли и на их месте поставили двухвартирный дом. В результате получился один дом с двумя адресами. Пришлось дом разрезать на 2 части и каждой присвоить свой адрес. Больше ничего подобного не видел.
dom1n1k
29.10.2015 14:57«Любые тэги» — самое большое проклятие осма. Видно, что изобретали его люди с линуксом головного мозга. Если бы сформулировать это хотя бы как "допускаются кастомные тэги" — уже было бы намного лучше. Да, возможности кастомизации и подстройки под частности нужны — но основное ядро должно быть тщательно продумано и стандартизировано. Мне казалось, что это аксиомная аксиома. Ан нет, кто-то любит себе проблемы создавать под предлогом свободы и настраиваемости :)
Moskus
29.10.2015 20:50+2Строго говоря, оно так и есть на практике — допускаются любые пользовательские теги. То есть если вы хотите вносить какие-нибудь диковинные признаки (скажем, толщину стен домов, если вы ее знаете и она зачем-то вам нужна) вы можете, никого не спрашивая, ввести новый ключ, описать его в Wiki (чтобы у людей не возникало вопроса, а что это за тег) и назначать. А если это что-то для общего употребления, то следует пройти процедуру внесения предложения, его обсуждения и голосования. Но во-первых, даже обсуждение и голосование не гарантируют, что плохой, бестолковый тег не будет принят. Во-вторых, даже официально не одобренные теги становятся общеупотребительными, особенно когда они с горем пополам позволяют обозначить то, для чего нормальной схемы до этого придумано не было — есть множество участников, у которых зудит в каком-то месте, только дай что-то обозначить. А хорош или плох способ — их не очень волнует.
Так что зло не в том, что можно придумать любой тег, а в том, что любой тег может, в конце концов, стать общеупотребительным, несмотря на свою бессмысленность. И это, фактически, ворует у проекта возможность иметь качественное обозначение, потому что когда какое-то уже есть, изменить его — уже куда сложнее.
igor_suhorukov
29.10.2015 17:16С одной стороны да, бардак есть. Особенно это ощущал, когда делал справочник адресов для Москвы из выгрузки OSM. Где-то есть КЛАДР код, бывает информация ОКАТО. Хотелось найти парсер названий и что есть улица, что переулок, что проезд и т.д
Но вот постороение онтологий для обозначений значительно уменьшило бы количество вносимых данных в карту. А так они вроде есть и вроде нетMoskus
29.10.2015 20:43Улица, переулок и проезд — это части названий. Также как street, avenue, gata, katu и прочее. Типы улиц в OSM определяются не этим, а использованием и значимостью в дорожной сети.
Что касается уменьшения объема вносимых данных — я не уверен, что качественные классификации могут реально помешать что-то вносить. Тем более, что бездумно можно выбрать произвольный тег, который просто кажется подходящим. Разница в том, что сейчас и те, кто думают над значением тегов, и те, кто об этом не думают, в определенных случаях вносят неопределенные данные, значение которых слишком размыто, чтобы их использовать каким-то полезным образом.
bpeme4ko
29.10.2015 18:15>> даже многие опытные участники проекта не понимают этой проблемы или понимают ее, но утверждают, что она незначительна
Не знаю, насколько я опытный участник (265 правок), но меня тоже как-то не убедило большинство приведенных в статье примеров.Moskus
29.10.2015 20:37Опыт определяется не количеством правок, а тем, пытались ли вы использовать данные, а не только вносить. При чем именно такие данные, которые используют теги с перечисленными выше проблемами. И тем, как вы эти проблемы для себя решили. Ну и встречный вопрос: как вы для себя решаете, что перед вами, kiosk, convenience shop, supermarket? И каким редактором вы пользуетесь — iD или JOSM? Используете ли пресеты в JOSM или пишете теги вручную?
shoorick
29.10.2015 21:07В том же JOSM иногда проще/быстрее внести тэг вручную.
Moskus
29.10.2015 21:20Я про iD спросил не потому, что «JOSM — для крутых, iD — для лохов», а потому, что в iD сам по себе механизм ввода обозначения предполагает, что человек берет и начинает писать слово, которое относится к обозначаемому объекту. Это как-бы прячет реальные теги от пользователя, то есть он их, теоретически, может вообще не видеть. И не задумываться, соответственно, ни о чем, потому что для этого нет никаких причин: он думает, что раз он написал там «супермаркет», то система как-то сама разберется, какой тип присвоить и так далее. В JOSM это невозможно даже с использованием пресетов — пользователь всегда видит получившиеся теги, а потому, у него есть хоть какая-то пища для ума на эту тему.
bpeme4ko
30.10.2015 02:00Мир не идеален, вот что я думаю :) При всех своих недостках OSM дает порой такие данные, которых нигде больше нет.
Пользуюсь JOSM, пресетов стало гораздо больше и это славно, но иногда все равно приходится в wiki лезть за тэгами.
Kiosk — совсем небольшой по площади, зато у него хорошие часы работы. Сonvenience shop — небольшой магазинчик на углу, побольше площадь и ассортимент. Supermarket — еще больше по площади, часто там есть что-то иное, чем просто еда + мыло и зубная паста. Например, там могут быть баллоны для газовых горелок, одежда, еще что-то полезное, но редко нужное.
В общем-то все это не очень важно, т.к. большинство магазинов выглядят на карте одинаково (тележка).bpeme4ko
30.10.2015 02:01А вот то, что реально важно — это чтобы вообще на карте было что-то отмечено, пусть и не очень точно. Мне гораздо больше поможет информация о том, что в каком-то населенном пункте есть два магазина и три кафе, чем информация о том, какие они.
Moskus
30.10.2015 02:53Ваша позиция по этому вопросу вполне объяснима: во-первых, вы не используете сами данные OSM, вы используете карту на их основе, которая является самым примитивным вариантом производного продукта из этих данных. Лично вам (подчеркиваю — лично) сгодилось бы, вероятно, даже если бы все было отмечено просто «магазин». Естественно, человеку, который весьма ограничен в своих запросах и оценивает ситуацию только по себе, сложно или почти невозможно представить себе проблемы, стоящие, например, перед создателями каталогов POI или перед теми, кто настраивает поисковые системы. Ваш случай — то, что в науке называется «вырожденный». И по нему судить об общей ситуации абсолютно неверно.
bpeme4ko
30.10.2015 03:02Так OSM же делается людьми для людей в первую очередь, а не для создателей каталогов POI. Те, кто профессионально заинтересован в подобного рода данных, имеют совершенно иные требования и возможности, поэтому они могут создать/купить свою карту, а не говорить пользователям OSM, что они что-то делают не так. Зачем пользователю заниматься в свое свободное время точной классификацией того, что он все равно не увидит?
Moskus
30.10.2015 04:27+2У вас весьма ограниченное представление о проекте и его задачах.
Во-первых, известное правило «не рисовать под рендер» и само существование огромного количества ключей, содержимое которых никак не отображается ни в одной из растровых карт, четко указывают на то, что OSM — это нечто несравнимо большее, чем карта на osm.org
Во-вторых, проект хоть и называется OpenStreetMap, но исходные данные распространяются под Open Database License, и эта база — первична, а все картинки, которые на ее основе создаются — вторичны.
В-третьих, те самые люди, для которых все это создается, пользуются вторичными, производными продуктами: онлайн-сервисами карт, картами, встроенными в картографические приложения вроде OSMAnd, Maps.ME, альтернативными картами для навигаторов Garmin, ПРО Город, Автоспутник и так далее. Также, выгрузки из OSM в виде shape-файлов использует невообразимое число отдельных разработчиков и сервисов. И это все — для людей. Если бы задачей OSM было рисование единственной карты, то у нас был бы графический редактор, а не JOSM или iD с весьма сложными структурами векторной геометрии и семантической атрибутики.
В-четвертых, есть целые сервис, являющийся органической частью проекта, overpass-turbo.eu предназначенный для выборок по сложным пространственным и логическим запросам. Плюс — публикация planet.osm и diff-файлов к нему, именно для нужд обеспечения доступности исходных данных. Если бы задачей проекта была карта-картинка, этого всего бы, вероятно, просто не было.
Собственно, многие из тех сервисов и навигационных средств для своего функционирования создают те самые каталоги POI и системы поиска. То же можно сказать о системах роутинга (прокладки маршрута).
И вот там во всей красе расцветают все те атрибуты, которые мы не видим на карте стандартного стиля на osm.org: время работы магазинов, назначение социальных учреждений, запреты поворотов на улицах, ограничения скорости и прочее. К большому сожалению, таких как вы — очень много, и эти люди вносят в базу только то, что видно на карте. Это, конечно, тоже какой-то вклад, но заведомое ограничение информации только этим делает базу неполной.
Так что ваше понимание — узко и приземленно. Так что или изучите предмет лучше, или не спорьте упорно о том, о чем знаете очень мало.bpeme4ko
30.10.2015 16:32+1Звучит убедительно, но наезды на конкретного человека не приносят никакой пользы ни Вам, ни проекту OSM.
Если конечные пользователи делают что-то «неправильно», то на это можно повлиять техническими средствами (удобными редакторами со стандартизированным набором тэгов), предупреждениями о недопустимых сочетаниях тэгов и т.д., но никак не морализаторством и обвинениями.
P.S. В точности то же самое наблюдается при строительстве некоторых городов. Проектировщики создают сложное и нелогичное окружение, а люди потом используют его «неправильно» — вытаптывают тропинки для обеспечения самого быстрого пути, переходят на красный в определенных местах гораздо чаще, чем в других, игнорируют нелогично проложенные велодорожки и т.д. В городах, где есть разум, окружение потом приводят под нужды людей. В остальных городах выставляют полицейских, чтобы они штрафовали за «неправильное» поведение, пишут в газетах о нарушителях порядка и т.д.Moskus
30.10.2015 20:05Сделайте что-нибудь со своей чувствительностью к критике — если вы любую критику считаете наездом, то это ваша проблема. А от того, что вашу безграмотность кто-то покритиковал, целому проекту — ни жарко, ни холодно.
vlivyur
02.11.2015 13:14Пиво/водку/сигареты куда идти покупать, если возле дома есть kiosk? Ещё не так давно можно было всё это купить именно в нём. Сейчас водку точно нельзя там купить. Ну и как бы kiosk сам по себе не магазин ни капли, сейчас часто вижу building=kiosk, а в shop пишут уже что-то осмысленное.
Самое главное — быстро найти такой магазин где ты можешь всё что тебе требуется купить. В незнакомом городе зарядник для ноутбука не найдёшь (как бы computer должно быть наверняка, но может быть ещё и в electronics, и в mobile_phone), если по названию магазина не можешь определить ассортимент. Т.е. очень много остаётся тыкательного поиска, чем и приходится заниматься.
Ну и пример с лечебными учреждениями: в Новосибирске были очень популярны клиники типа «гинеколог/стоматолог» — как такое одним тегом обозначить? А кафе + кондитерская + пекарня? Или мастерская «минутка» — ателье, ключи, обувь? А какая разница между supermarket и department_store, и в чём проблема для покупателя что их разделили на два различных магазина? Вот и приходится выбирать что-то одно имеющееся, а остальное хотя бы в description пытаться втиснуть.
Самый жизненный пример осмысленного тегирования — АЗС, на форуме неоднократно всплывало «не нужны мне АЗС, хочу АГЗС». Вот теперь эти люди могут и затегировать и найти такие заправки. А так-то wikimapia уже давно существует, и если есть желание, то на примере, опять же, Новосибирска (ему совсем не повезло, никто им не занимается ибо ДубльГИС родом оттуда) можно попытаться найти что-то нужное, там пользователи очень хорошо применили навыки wikimapia в osm.Moskus
02.11.2015 20:20Напрягите логику, пожалуйста.
Если возле дома есть shop=kiosk, то там может оказаться что угодно — от исключительно сигарет до исключительно игрушек, потому что ассортимент за этим тегом не закреплен. И такого — пятьдесят тысяч вхождений в базе.
Почему вы решили, что клинику «гинеколог/стоматолог» нужно обозначать одним тегом? Читайте healthcare 2.0. Вы просто плохо ориентируетесь в системах обозначений, потому вам кажется, что есть проблемы, которых на самом деле нет.
Вопросы по поводу АЗС/АГЗС — того же порядка: кто-то не знает про wiki.openstreetmap.org/wiki/Key:fuel
И с Викимапии пример брать абсолютно нечего — нет там ни одной положительной практики, пригодной для OSM. Так что все — мимо.vlivyur
03.11.2015 01:08Перечитайте начиная с комментария на который я отвечал, пожалуйста.
Проблемы были и их в hc2.0 и fuel успешно решили (пожарники и лесники тоже в этом списке), но в остальных случаях (shop/amenity/craft/highway/natural) проблемы так и остались, никто их не решает (opensource же), но хоть споры не утихают. С кондитерской/пекарней и «минуткой» что делать-то будем?
Новосибирск в OSM уже успешно наполовину заполнен в духе wikimapia и это был пример достаточной карты, судя по описанию bpeme4ko.
diomas
29.10.2015 22:04Очень хорошо обозначена проблема. Но уйти от нее ой как тяжело: поменять принцип тегирования от общего к частному. Да, в отдельных областях типа healthcare, это почти получилось, но все эти убеждения и споры на форуме иногда выглядят как борьба с ветряными мельницами.
Фактически, это единственный путь сохранить гибкость и максимально формализовать данные: использовать атомарные теги для обозначения конкретных независимых свойств по отдельности, а не пытаться засунуть в значение тега, комплекс субъективно подразумеваемых свойств, придумывая новые собирательные категории и переосмысливая значения старых.
Людям с системным мышлением очень тяжело влиться в ОСМ, когда они встречают такие дикие вещи как противопоставление «сладкого», «твердого» и «зеленого». Или, например, непоследовательность с «shop» и «amenity». Вот начинающий маппер видит shop=bycicle, shop=grocery, shop=clothes, amenity=cafe, amenity=library, amenity=parking, amenity=car_wash и у него может сложится представление, что он все понял, мол, ага, значит shop — это продажа товаров (по разным типам), а amenity — это, похоже, место предоставления каких-либо услуг. Потом он видит shop=hairdresser, shop=beauty, shop=copyshop, shop=laundry и понимает, что shop это и услуги тоже. Потом он видит shop=mall, shop=kiosk и понимает, что значение shop — это не обязательно вид товара/услуги. Потом замечает, что highway означает не только условный статус дороги, а может означать также ее покрытие, скоростной режим и назначение (track, motorway), или может обозначать всякие объекты на дороге: crossing, traffic_signals, или вообще то, что почему-то не попало в amenity/shop: services, rest_area, phone. И уходитв монастырьмапить в народные карты.Moskus
29.10.2015 22:23Вы так говорите про Народные Карты, будто там — порядок с этим вопросом.
Да, там есть фиксированный набор типов, но этот набор навечно заморожен, а потому люди, у которых зуд, отмечают все, что только взбредет в голову, подписывая это словами. Ну и некорректно сравнивать международный проект, данные из которого доступны всем и каждому (даже с учетом всех его несовершенств), с проприетарной кормушкой для фанатов Яндекса.
Все, как всегда, зависит от людей. Пока те, кто не видят в этом проблемы, потому что либо не обладают системным мышлением, либо никогда не пытались использовать данные OSM самостоятельно, находятся в некотором подавляющем большинстве, такое безобразие и будет твориться. Теоретически, можно предположить, что какая-нибудь компания, использующая данные OSM, где мучаются с их конвертированием, может предложить какие-то схемы обозначений, разработанные более профессионально. Таких прецедентов пока нет. Есть отдаленно похожие — например, сотрудники картографического подразделения «Спутника» часто тормошат людей на форуме на тему того, какие обозначения поддерживать для каких-то чисто российских объектов. Например, недавно таким образом дошли руки до молочных кухонь. На счастье, получилось выработать расширение схемыsocial_facility=*, вместо того, чтобы бездумно добавить еще один тип вamenity=*. Может так дойдет и до чего-то другого, постепенно. Но совсем исключать возможность изменений, а потому вообще не пытаться ничего сделать — неправильно.diomas
29.10.2015 23:57про уход в народные карты я упомянул скорее как про крайнюю форму отчаяния, а не как что-то приемлемое в плане категоризации, по тому, что я видел, там все очень скудно: с ОСМ даже сравнивать не стоит.
и да, я не говорю, что не стоит ничего делать, делать надо, просто будет очень сложноMoskus
30.10.2015 02:57Почему «будет»? Оно есть сложно. Но оно делается, понемногу.
Хотелось бы большего понимания проблемы со стороны пользователей (хотя по поводу большинства я иллюзий не имею). Для чего, в том числе, эта статья.
ru7701
03.11.2015 23:34«Но оно делается, понемногу» — похоже на оправдание. Процесс ради процесса. Большие профи в области онтологий вроде Левенчука свидетельствуют, что дела в этой сфере плохи. Сама по себе идея их формирования не «выстреливает». Так зачем биться в стену?
По мне так лучше бы в ОSM за основу взяли какую-нибудь графовую СУБД («использовать атомарные теги») и посмотрели как это отобразится на результате.
Впрочем, сама по себе статья очень интересна и даже изумительна по доходчивости. Браво!Moskus
04.11.2015 00:29Редактирование OSM во многом, действительно, «процесс ради процесса» вообще. Хотя бы по той причине, что множество тегов нигде не только не отображаются, но и не поддерживаются. Так что это некий «дзен».
Поскольку проект, в то же время, крайне анархический, то есть даже OSMF не имеет сколько-нибудь заметной власти над происходящим, идеи вроде «лучше взять графовую СУБД» утопичны чисто технически. Я понимаю, что вы этого не предлагаете, но, тем не менее, проекту так или иначе приходится обходиться тем, что есть. Иллюзий у меня нет и оправдывать я никого не собираюсь, тем более, что некоторые участники проекта, что в России, что в других странах — сторонники полного анархизма, которым прикрывают решение своих частных задач и удовлетворение собственных амбиций (рисование под рендер, расширительная трактовка значений тегов вместо внедрения новых и так далее). Но в то же время, OSM — проект, в котором иногда отдельные участники могут изменить многое почти что одним движением. Свежие примеры — это leaf_type и leaf_cycle, а также ситуация со стандартным стилем (см. недавнее изменение способов отображения дорог). Так что да, все довольно запущено, дураков среди участников достаточно, но это пока не переросло в необратимо негативную ситуацию.
За оценку статьи — спасибо.ru7701
04.11.2015 00:58Ну если «переход на графовые базы данных» — утопия, то наверное ситуация у вас в ОSM может сильно улучшиться с приходом нейронных сеток. Когда за семантический слой будут отвечать не белковые/ленивые анархисты, а кремниевые трудяги. Сейчас там бурный подъем. Натаскиваешь такую сеточку на правильное тегирование медицинских объектов по Healthcare и далее она пускается в свободный мониторинг реальности: видит, допустим, в гугл-стрит новую больницу и сама все супер-верно все размечает в ОSM, попутно еще выспрашивая у кого надо подробности.
По поводу статьи мне есть с чем сравнивать: в более близкой для меня теме semantic-web собственно такие же корневые проблемы с заразительной активностью апологетов, но слабой методологической базой всего проекта. И там вот не дай бог сказать — «топчитесь». А при этом уровень популяризаторских статей средненький.Moskus
04.11.2015 01:18На самом деле, даже более приличные пресеты для редакторов OSM могут дать заметное улучшение, потому что множество сущностей действительно весьма однотипны и предложив людям готовый шаблон, можно уменьшить число ошибок. В том же iD (который веб-редактор, встроенный в osm.org) русскоязычные метки часто просто ужасны и вводят в заблуждение. А в JOSM они не входят в комплект по умолчанию (или входят, но не те, что надо).
ED98
30.10.2015 19:57barrier=bollard
Хе-хе, хотел бы я посмотреть на «барьер, убираемый, бетонный, высотой 70 см» :)
bollard=removable
material=concrete
height=0.7
highway=alley
Наверное, highway=service + service=alley?
Вики-страница этого тегаvlivyur
02.11.2015 13:24Конечно про неё, просто автор сократил, я по памяти тоже помню именно как highway=alley.
Ну и если width=0.01, то не вижу проблем.
barrier=bollard
Тут кстати тоже разброд и шатание, ибо в других тегах уточнение задавалось бы в духе barrier:type или barrier_type или даже bollard:type/bollard_type, что опять же не снижает порог вхождения. Плохо что в редакторах кишки наружу торчат, если бы сделали это более юзерфрендли, то может и пошёл бы продукт в массы.
bollard=removableED98
02.11.2015 14:37Тут кстати тоже разброд и шатание, ибо в других тегах уточнение задавалось бы в духе barrier:type или barrier_type
Считаю, что части ":type" и "_type" не несут никакого смысла, поэтому их можно отбросить.
Плохо что в редакторах кишки наружу торчат
Не знаю, в JOSM все ":type", "_type" и прочие выдумки мапперов спрятаны за чекбоксами и выдающими меню, в которых стоят понятные слова на человеческом языке.
Это сложно для программистов, которые используют данные OSM и вынуждены проверять, где используется ":type", где — "_type", а где — ещё что-то.
если бы сделали это более юзерфрендли, то может и пошёл бы продукт в массы.
А сейчас OpenStreetMap не «в массах»? :)
vlivyur
03.11.2015 00:44Сейчас не в массах. На регион приходится с десяток более-менее постоянных мапперов. Иногда можно увидеть «смотри какая клёвая карта», а чаще сам показываю. На фразу «её и редактировать можно» можно услышать от «ммм» до «нахернужно».
JOSM сам по себе неинтуитивен для новичка. Пресеты не на всё есть, и не всё в них есть, так что периодически приходится лезть в вики и смотреть как же всё-таки правильно. Понятные слова, к примеру, в biycle_parking (building или shed, ну может где-то в Японии с ихними автоматическими парковками работает и это), мало чем помогают.
Считаю, что части ":type" и "_type" не несут никакого смысла, поэтому их можно отбросить.
На форуме в теме «одно или двухвейная улица» периодически заикаются про маршрутизацию для спецтранспорта, которому двухвейность не должна быть препятствием для манёвров через двойную сплошную, так же и некоторые типы barrier. То же самое можно сказать про велосипедистов.ED98
03.11.2015 01:30
Извините, это здесь при чём?Считаю, что части ":type" и "_type" не несут никакого смысла, поэтому их можно отбросить.
На форуме в теме «одно или двухвейная улица» периодически заикаются про маршрутизацию для спецтранспорта, которому двухвейность не должна быть препятствием для манёвров через двойную сплошную, так же и некоторые типы barrier. То же самое можно сказать про велосипедистов.
Я имел в виду, что между ключами что-то:type=*, что-то_type=* и что-то=* нет никакой разницы, поэтому лучше использовать ключ что-то=*.
Я не говорил, что уточняющие теги не несут смысла.
Я говорил только о том, какую «форму», какой «шаблон» правильнее использовать для уточняющих тегов.vlivyur
03.11.2015 09:47Исходное
ключ=значение
Для этого в данный момент для разных ключей применяются различные схемы уточняющих тегов:
значение:type=*
Что оставляем? Если вы за
значение_type=*
значение=*
ключ_type=*
ключ:type=*значение=*(ну и любой другой использующийзначениев качестве ключа), то, на мой взгляд, это очень плохая схема, т.к. изначально не известно каким будет уточняющий тег.ED98
03.11.2015 10:14Да, использовать значение=* в качестве ключа уточняющего тега можно только тогда, когда данное свойство относится только к данному объекту, а не ко всей категории. Например, мы можем использовать residential=urban/rural, потому что residential=* относится только к landuse=residential, а не ко всем landuse=*.
Если же свойство относится ко всей категории (например, building:levels=* относится ко всем building=*), то в ключе уточняющего тега должен стоять ключ основного тега, а не какое-нибудь его значение. И тут не обойтись без *:type=*, да.
Когда писал, что *:type=* не имеет смысла, рассматривал только первый вариант. Почему-то не упомянул это, извините.
TrueBers
Сколько ни пытался начать коммитить в осм, именно эти странности с тегами сбивали с толку.