30 заметок с тегом

пропозалы

Позднее Ctrl + ↑

ЛЭП

После длительного спора о замене power=cable на power=linelocation=underground Франсуа Лакомб решил восстановить два старых пропозала: про производство и передачу электроэнергии. На нашем форуме совершенно независимо ожила релевантная тема.

В первом пропозале, за который уже голосовали, но всего восемь человек (недостаточно для принятия), предлагается отменить слишком размытый тег power=station (заменив его на power=plant или подстанцию) и переименовать sub_station (станция субмарин) в substation (подстанция). Трансформаторные подстанции нужно будет отмечать как power=transformer — то есть, все уже обозначенные в ваших городах ТП придётся переделать (а может и нет — см. комментарии). Текст предложения уже достаточно подробен, голосование планируется открыть через месяц.

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



Пропозал про линии электропередач пока весьма сыр, но суть уже ясна: все линии обозначаются как power=line, расположение записывается в location, а напряжение — в voltage, при этом необязательно считать изоляторы для получения точного значения, а можно использовать слова low / medium / high. Границы ещё обсуждаются, пока предлагают 1 и 50 киловольт. Уход от power=cable некоторые воспринимают болезненно, исписывая десятки килобайт не только в рассылке, но и в обсуждении пропозала.

Также непонятно, что делать, когда через опору проходят несколько линий. Общее мнение — что придётся использовать отношения, только какие именно? Лагеря два: за type=route с route=power и за другие type: встречаются power и power_circuit. Противники первой схемы утверждают, что type=route подразумевает, что по линиям такого отношения можно проехать, а то и пустить общественный транспорт — троллейбусы, например.

Вопросов пока не вызывает только деление опор на power=tower и power=pole: первым тегом обозначаются большие, нередко металлические ажурные конструкции для линий среднего и большого напряжения, а вторым — простые столбы, обычно деревянные или бетонные. Впрочем, стоит собрать галерею — и классификация местами оказывается затруднительной.

Для понимания всех упомянутых страниц, споров, схем и матчасти рекомендую статью Алексея Толмачёва: чередуя короткие абзацы и фотографии, он доходчиво объясняет, на что смотреть, оказавшись рядом с подстанцией или опорой линии электропередач.
 20 комментариев   2013   пропозалы

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

Недавно 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 комментариев   2012   wiki   пропозалы   теги

Десятки миллиардов отношений

Dr&mx навёл на великолепный пропозал отношения, которое широко используется в Польше: type=person. Оно связывает места рождения и смерти человека, а также место захоронения и памятники. И разумеется, отношения могут быть связаны друг с другом по родству (с закольцовыванием parent-child). Сделан этот пропозал специально для использования на кладбищах, к нему прилагается пресет и плагин для JOSM.

Могилы же отмечаются как tomb=* (тоже ссылка на польскую страницу: в английском переводе ограничились общим описанием). Интересно, что их количество в базе не сильно превышает количество отношений person. Возможно, американцы и итальянцы, также детализировавшие несколько кладбищ, удержались от создания отношения на каждого человека.
 9 комментариев   2012   пропозалы

Пропозал childcare не прошёл, потому что вы все мужчины и не понимаете



После пламенного доклада Моники хочется сразу возражать и требовать объективности (как немцы), но нельзя отрицать, что проблемы актуальны: картостиль выпячивает определённые заведения, тегов для детских заведений маловато, а механизму пропозалов всё меньше доверия.
 18 комментариев   2012   видео   пропозалы

Граф на графе

Немцы сочинили очередной грандиозный пропозал, но на этот раз — с практическим смыслом. Для обозначения рёбер TMC (пробочного радиосервиса со стандартизованным протоколом) раньше использовались жуткие теги, которые предлагается заменить одним, с читаемым значением вида tmc=DE:12345+58934. Текст пропозала пока написан только на немецком языке, но иллюстраций и примеров столько, что понятно и так. Tobias Knerr доходчиво объяснил преимущества новой схемы, а спустя неделю Eckhart Wörner перечислил её недостатки в практических применениях.

В России по данным википедии услуги RDS-TMC предоставляет Навиком, но они поддерживаются только некоторыми моделями Garmin, найти номера рёбер для улиц в сети невозможно, а ограничения протокола делают сервис в больших городах почти бесполезным: посмотрите, например, на эти карты. В обсуждениях пробок на карте OSM чаще всплывает название OpenLR — но о поддержке этого сервиса даже в Европе ничего не известно.
 3 комментария   2012   пропозалы
Ранее Ctrl + ↓

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