Глобально устаревшая схема тегирования

Недавно ErshKUS и Komяpa вновь подняли в чатике вопрос автоматической замены building=entrance на entrance=yes: после прошлогоднего голосования за новый вариант обозначения сотни тысяч «старых» тегов мозолят некоторым участникам сообщества глаза. И тут же обнаружилось, что pschonmann без спроса взял и загрузил огромные ченджсеты, где не только исправил спорный тег, но и другие, которые валидатор KeepRight пометил как устаревшие. Разумеется, DWG всё это откатила на следующий день.

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

Разумеется, околотехнические гики, из которых OSM состоит чуть менее чем полностью, сразу выбрали второй вариант: как же так, база данных не соответствует схеме! И бросились обсуждать технические мелочи: величину переходного периода, последовательность действий, зоны ответственности. Чтобы не вовлекать страшный DWG, сразу отметили, что такие замены лучше делать в пределах одной страны. Проблема же в том, что изначальная постановка вопроса некорректна. И более того, она базируется на двух неверных предпосылках: 1) механизм пропозалов имеет смысл; 2) вики определяет используемые теги.

Модель тегирования в OpenStreetMap зиждется на принципе «Any tags you like»: у нас свободная база и никто не может указать, какой тег использовать. Другой вопрос, что если ваш тег никто не понимает, то он бесполезен. Поэтому все используемые теги очень желательно документировать в вики. Многие так и поступают: в нашей вики можно найти множество страниц, посвящённых очень редким тегам. Ссылки на такие страницы объединяются в каталоги по типам, а каталоги фильтруются и объединяются в колоссальные страницы «Map Features» и «How To Map A». Благодаря этой документации вам не нужно придумывать и продвигать тег каждый раз, когда вы встречаете что-то новое: большинство объектов уже имеют обозначения, и найти их не очень сложно.

Вместо создания вики-страницы втихаря, можно организовать пропозал: предложить модель тегирования, обсудить её с другими мапперами и проголосовать за её использование. Тем самым схема оттачивается, а голоса, отданные в её пользу, добавляют ей веса: после принятия сложно будет оспаривать место нового тега в общеупотребимых таблицах. Особенно это полезно, когда разные участники предлагают разные схемы тегирования одного и того же: победивший пропозал определит теги, используемые тысячами мапперов. И поскольку тегов уже очень много, не удивительно, что некоторые пропозалы, расширяя схему тегирования, делают некоторые теги ненужными.

Постоянное упоминание пропозалов привело к тому, что мапперы выдвигают их до того, как что-то закартировать с использованием предлагаемых тегов. Затем тратят месяц на споры, полировку схемы и обслуживание голосования. И потом не понимают, что делать, если схема оказалась отвергнута. Или хуже — принята. Объём бюрократии чудовищен, и всё ради включения в обсуждение лишних 20 человек. Разумеется, в их числе не будет пользователей новой модели тегирования, не будет мапперов, нуждающихся в этом теге, и не будет специалистов по обсуждаемой предметной области. В итоге многие современные теги остаются без описания в вики, потому что новички боятся создавать страницы тегов, минуя пропозалы, а главным информационным сайтом стал TagInfo.

Другими словами, вики создавалась, чтобы описывать используемые теги. Со временем часть мапперов решила, что вики первична: как тaм написано, только так и можно мапить. Поэтому они начали смотреть на пропозалы как на директивы, создавая их, когда тег почти не представлен в базе и чувствуя, что как только схему примут, все станут на неё смотреть и использовать, и уже ничего не изменишь. Отсюда родились вики-бюрократы, следящие, чтобы каждый принятый пропозал был идеален. Жёсткость схемы привела к тому, что пропозалы стали создаваться не только для введения новых тегов, но и для изменения существующих схем. При этом, как видно, основания у этого нет: кажущаяся директивность, со всеми устареваниями тегов и требованиями мапить правильно, основывается на неверной предпосылке первичности вики. В реальности хорошо если одна десятая мапперов вообще в курсе, что по решению десятка человек может поменяться тег, использованный сотни тысяч раз. Поэтому поставленный Hind вопрос нужно рассматривать не в контексте «заменить устаревшую схему на новую», а как «у нас есть один распространённый тег, давайте заменим его на другой».

Теперь посмотрим, что на что предлагается заменить. В модели тегирования OSM есть каскадные теги (они тоже нравятся не всем, но практика устоялась). Например, highway=crossing + crossing=uncontrolled или natural=water + water=pond. Второй тег уточняет первый, но без него смысл тоже понятен. А что если мы введём crossing=yes и water=yes? Внезапно, первый тег стал не нужен! Уточняющие теги почти всегда уточняют один фиксированный тег. Избыточность в нашей базе, неужели у вас не чешутся руки её поправить? Давайте сделаем water=yes и устраним natural=water! То есть, давайте, раз случайно приняли entrance=yes, устраним building=entrance. Аргументация «за» и «против» для обоих предложений не может отличаться, и в контексте становится более понятной. Например, давайте перевернём в соответствии с известностью тегов: если на входе есть building=entrance, зачем ставить дополнительно entrance=yes? Устранение building=entrance совершенно немотивировано («но так же лучше» — это не мотив, всё работало и до пропозала) и касается тега, используемого более половины жизни проекта.

Получается, вопрос касается только массовой правки с указанными параметрами, но при этом с подразумеваемым упрощением принятия решений по последующим подобным правкам (как crossing=yes). Без опоры на «устаревший тег» и «актуальную схему». Сообщество совершило ошибку, приняв тег, эквивалентный уже используемому, и решение может быть только одно: во всех программах теперь нужно поддерживать оба. Глупо ожидать, что после правки building=entrance перестанут использовать: продолжат — вики же не директивна, — и пользователям не резон удалять строчку из программы для этого тега.

Моё отношение к массовым правкам, будь то импорты или ковровые замены тегов, известно: лучше не надо. На мой взгляд, они лишают базу «жизни», закрепляют её состояние и дают пользователям ложное ощущение стабильности. Участникам OpenStreetMap, программистам, значительно проще написать робота, нежели аргументировать его использование. Так, предлагаемая массовая правка предсказуемо не следует правилам OSMF для массовых правок, на которые ссылается страница «устаревших тегов». Вместо этого инициаторы «по-русски» хотят договориться с, судя по форуму, новичками и быстренько провернуть замену. Предложения написать в DWG или, как минимум, оповестить tagging@ сталкиваются с непониманием и страхом: вдруг откажут? По-моему, это — первый признак того, что вопрос перехода на новую схему вообще не стоит (а не «я выбираю первый вариант»), и что проблема «неактуальной тягомотины» надумана и раздута, не столько ради этой конкретной замены, сколько для оправдания будущих масштабных актов наведения порядка в базе.
Поделиться
Отправить
27 комментариев
Hind
> она базируется на двух неверных предпосылках
Што? Я как раз писал так, чтобы не привязываться к таким механизмам, как пропозалы и т. п.
Это был пример.
Hind
> никто не может указать, какой тег использовать.
Это не так. Если ты начнешь писать описание объекта в тег building, твои правки будут откатывать. Догадайся, почему. Потому что де-факто есть стандарт.

А ещё бывают случае, когда де-факто есть будущий стандарт. И вот о таких случаях наша тема.
Hind
> инициаторы «по-русски» хотят договориться с, судя по форуму, новичками и быстренько провернуть замену
Это тоже не так. Новички могут хотеть и писать что угодно, но тема посвящена выработке методологии. Глобальной.
Hind
> оправдания будущих масштабных актов наведения порядка в базе

Отлично, наведение порядка уже нуждается в оправданиях. А наведение беспорядка (использовать обе схемы), видимо, не нуждается.

В общем, ты с постом поспешил, и вместо участия в обсуждении выкатил вот этот текст. Хотя обсуждение было инициировано тобой.
ErshKUS
А Евгений тоже видимо гиг :)
Илья «Zverik»
1. То есть, ты оперируешь терминами «устаревшей» и «актуальной» схемы тегирования, даже минуя этап их принятия? Тег entrance=yes был принят через пропозал, отвязаться от него ты не сможешь.
  1. Неправда. Загляни в конец http://taginfo.openstreetmap.org/keys/building#values — никто эти правки не откатывал. Стандартов нет, есть список наиболее употребимых значений.
  2. Методологии для чего? Чем не устраивают правила проведения массовых правок, неоднократно обсуждённые в списках рассылки и утверждённые OSMF?
  3. Не нуждается, потому что беспорядок — основа OpenStreetMap. Более того, «наведение порядка» должно быть в кавычках, потому что в рамках модели OSM это невозможно. Ты лишь хочешь подменить один беспорядок другим, менее заметным. Замести крошки под диван.
ErshKUS
1. А не приходило мнение что переход от множественности одинаковых тегов к стандартизации это эволюция ОСМ («ну раз он живой»).
2. Зверик, ты уж больно много неточностей (мягко говоря) написал насчет обсуждения и прочего, прям как по телику в новостях.
3. Если каждый может изобретать свое тегирование, вот гипотетический вариант входящий в твои рамки: мне не совсем удобна текущая схема адресации, я возьму и повешу Параллельно свои придуманные теги, причем если они будут не так восприниматься мапником или конвертором (т. е. мои придуманные будут дублировать текущие, но иметь другой смысл) — наплевать. Ботом буду контролировать их актуальность. Неужели меня за такое не запинают и в первую очередь DWG?
4. Почему все кто против замены, считает что мы тут организовываем маленькое сообщество которое будет никого не спрашивая (без голосования) заменять любые теги на нам угодные?
5. ну и напоследок, тогда почему боты (например xybot) заменяли мои опечатки в тегах, а может это мною разработанный?

В общем правильно сказал Hind
lenux
Я думаю нужно сделать разграничение на Базовые тэги (например реки, дома и т. д.) и пользовательские (любые тэги). Базовые тэги курирует Совет Российского OSM. Так же в его функции было бы утверждение по принятию новых тэгов для обозначения того, что нету в базовом наборе. + поддержка стабильной редакции тэгов.
Система пропозолов в её виде мало эффективна (к примеру, что я только недавно узнал о том, что эти входы так уже не обозначают).
Илья «Zverik»
2ErshKUS
  1. Стандартизация — я только за. Но не путём массовых правок, а цивилизованно, через смену модели. Как я сказал, в текущей модели стандартов быть не может.
  2. Я вижу, что обсуждаются технические проблемы, а попытки выйти за их пределы сталкиваются с непониманием и откладыванием более важных проблем на потом. Для конструктивности ты можешь написать подробнее, в чём я неправ.
  3. Вешай, в чём проблема? Даже можешь дописать osm2mp, osmand и стили мапника в перспективе, и со временем твою схему будут использовать и другие участники, наравне с (или вообще вместо) принятой ныне. Это и называется do-ocracy. Главное — не портить раньше времени существующие используемые данные.
  4. А что вы создаёте? Пока что я вижу спор «запускать бота» против «не запускать и оставить базу покрываться плесенью». Судя по идиотизму постулата другая второна воспринимает это как-то иначе, но я, действительно, не очень понимаю, как.
4а. Но ясно вижу, что происходит очередное изобретение велосипеда, с отрицанием предыдущих практик (см. правила от OSMF). Причина — чтобы не пришлось иметь дело не только с новичками на форуме, но и с опытными членами международного сообщества OSM.
  1. Долгоиграющие боты следуют правилам. В частности, если что-то исправлено некорректно, можно связаться с автором бота и сказать об этом. Они не касаются схем тегирования и прочих опасных вопросов. Было немало примеров, когда робот начинал следить за схемами тегирования, и все они кончались выпиливанием бота.
5а. На секундочку, мы обсуждаем единовременную массовую замену, или робота, который будет следить за новыми использованиями building=entrance и оперативно их заменять? Потому что это, хотя и не переводит вопрос в новую плоскость, придаёт ему остроты: это будет первый случай в OSM, когда использование какого-то тега явно запрещено.
FSA
По моему всё-таки надо определиться как правильно тегировать. Пока я не вижу подъездов на Mapnik при любом увеличении ни с building=entrance, ни с entrance=yes. Есть конечно Космоснимки, но там кривая отрисовка с пропадающими домами. Подъезды есть, а дома нет.
Лично я и без бота переправлю теги на те, что будут приняты. Тем более, что в своём районе въездами/входами только я занимался.
Мак Сим
Мне, как программисту, хочется при работе с данными опираться на какой-то стандарт. То есть Я хочу быть уверенным, что у замкнутой линии не будет одновременно build=yes и natural=water. Я не хочу при обработке тегов проверять building=entrance и entrance=yes. Модель OSM не ограничивает фантазию в таких вопросах. То есть всё остаётся на совести конечных пользователей. По моему нужно оставить building=entrance для совместимости. Если мы сейчас забьём на вопросы обратной совместимости, то получим кучу проблем в будущем: приложения написанные до выхода какого-либо proposal могут перестать работать, если очередной бот удалит старый, но для кого-то очень важный тег.
Я бы очень хотел, чтобы у OSM был единый стандарт, единый набор правил обозначения объектов на карте. Но это уже будет совсем другой проект.
liosha
>> 4. Почему все кто против замены, считает что мы тут организовываем маленькое сообщество которое будет никого не спрашивая (без голосования) заменять любые теги на нам угодные?

Потому что только что это произошло с подъездами :D
ErshKUS
>> Потому что только что это произошло с подъездами :D
эх, так бы всегда. Слепил никакой сайт — а все его считают крутым...
вы бы хоть конкретные линки давали при подобных обвинениях
liosha
Ну как бы линк: http://shtosm.ru/2012/12/13/1
ErshKUS
ну так это Зверик себе придумал. Причем здесь это.
liosha
огромные ченджсеты™ он не придумал
ErshKUS
liosha, вы путаетесь. Это было до этого, Котяра сам решил заменить. Это совсем расходится с тем что предлагается в теме на форуме.
Zkir
>переход от множественности одинаковых тегов к стандартизации это эволюция ОСМ.

Во-первых это не эволюция, а навязчивая идея, мания.
Во-вторых, теги building=entrance и entrance=yes вовсе не(!) одинаковые. Это лишняя иллюстрация к тому, что товарищи, одержимые заменизмом, просто не хотят (не могут?) видеть очевидное.

building=entrance — это «вход в здание», «подъезд». А entrance=yes  — какая-то неведомая хрень.
ErshKUS
Zkir, странно, но так считаешь только ты, ну или немногие. Вам наверно сюда http://wiki.openstreetmap.org/wiki/Proposed_features/entrance
Zkir
ErshKUS, а не странно, что такая блестящая идея, быстренько заменить якобы устаревшие теги, наталкивается на серьезное сопротивление? В силу чего, по твоему мнению? Просто из-за тупости и косности Зверика, Лёши и ДВЖ ( ну и твоего покорного слуги)?

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

Не знаю как долго будет продолжаться, но это серьезно угнетает. Я боюсь это пофиг тем, кто делает кучу правок. Но всякий новичок, быстро вникнув в инструменты, сможет только фиксить баги (менять скорость дороги или добавлять новое здание). Но например, схему адресации домов или обозначение картографических деталей, постичь будет невероятно трудно.

P.S. : новичков достаточно часто вспоминают, что они использует странные теги как highway=hospital или менее странные, а профессионалам получается можно, все как получится и даже не переименуют... Дискриминация...
Виктор
Другая сторона вопроса — обратная совместимость.

Я все время хочу донести одну и ту же простую мысль. Не должно быть в OSM вечной обратной совместимости! Мы сами роем себе могилу. Если мы видим, что multipolygon тупиковая ветвь, мы должны остановиться!

Я догадываюсь, сколько вылетит какашек со стороны разработчиков, поэтому это должно быть запланированная акция, где будет составлен список и четко объяснен. Должны быть продуманы и подготовлены tools как osmosis. Программистов, которые не хотят обновлять свое приложение, все равно погубит время... Так что следут вести мажорные и минорные версии OSM. Мажорные для multipolygon и минорные для building=entrance...
bopoh13
Как уже кто-то писал здесь «у нас демократия». Несмотря на то, что примет большинство, — я за стандартизацию (причём полагается вначале делать проектную документацию, только потом реализовать в базе).
Так и было сделано, в основном англоязычными участниками, при изменении схемы обозначения входов. Но что европейцу хорошо, на то россиянину начихать.
FSA, +1. Но именно из-за вот таких длинных монологов я не спешу рисовать входы в подъезды.
Илья Зверев
Я уже давно рисую подъезды как entrance=yes. Пропозал приняли, поздновато метаться. Длинные монологи спровоцированы массовыми правками, а не изменением рекомендуемой схемы тегирования.
bopoh13
Илья, я имел ввиду не твой пост, а переписку на форуме.
suslikk
А я entrance=yes тоже везде пихаю, ибо мне для работы обозначение подъездов в доме очень критично. И сам очень быстро выпилил свои building=entrance. Кому верить не знаю...
Zkir
suslikk, а оно (entrance=yes ) _для тебя_ работает?
suslikk
Zkir, «оно» (подъезд) на меня работает :)