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

теги РСС

Дело о нотариусах

7 февраля, 20:58

(Фотография с пикабу)

Если кто-то хочет ввести в вики OpenStreetMap новый тег, нужно создать для него пропозал: страницу, объясняющую суть, модель тегирования и чем тег поможет. Процесс древний и хорошо документированный. Создав страницу, начните обсуждение в рассылку tagging@, через пару недель запускайте голосование, и его результаты покажут, насколько тег интересен другим мапперам. Правда, в рассылке живут около ста человек, голосуют 15-20, причём редко те же люди, которые тег потом будут использовать.

Пользователь Math1985 полгода назад проследил, как пропозалы, устаревания, картостиль и пресеты (заготовки) редакторов влияют на популярность тегов. Он воспользовался гениальной страницей Мартина Райфера, которая строит график популярности для любого количества тегов. Исследование Math1985 показало, что картостиль не влияет никак, вики влияет лишь поверхностно, а вот пресеты побеждают всё. Наиболее показателен случай shop=seafood против shop=fishmonger: в 2010 году первый победил второй в вики-голосовании, но благодаря Potlatch 2 и iD значений fishmonger было больше до 2014 года, когда пресеты в iD поправили.

Месяц назад один человек обозначил офис нотариуса как office=lawyer, а другой заметил это и вместо того, чтобы добавить уточняющий тег lawyer=notary, перетегировал в office=notary. Я про такой вариант не знал, на вопрос мне ответили, что этот тег указан в пресетах JOSM. Два тега для обозначения одного и того же — ненормально, поэтому углубляемся в историю.

В мае 2010 года в вики создали страницу для ключа office и 12 его популярных значений, включая office=lawyer. На странице для последнего сразу указали три возможных уточняющих тега, среди них — lawyer=notary. В тот месяц в рассылку tagging@ написали полтысячи писем, включая обсуждение shop=fishmonger, но не про office. Тем не менее, сразу после описания в вики на карте начали появляться офисы нотариусов, обозначенные задокументированной парой тегов.

Спустя четыре года, в марте 2014, пользователь CMartin отредактировал таблицу значений тега office, добавив туда пять строк, включая office=notary. На личное письмо он ответил, что обсуждения не было, он лишь внёс заметные значения из таблицы Taginfo. Через полгода строчку в таблице заметили и в её описании сослались на устоявшийся способ тегирования: office=lawyer. В таком виде список провисел до ноября 2016 года, когда Math1985 заменил его на автогенерируемый из Taginfo.

В ноябре 2015 года Klumumbus вытащил список значений office в заготовки JOSM. К этому моменту в базе было примерно 240 тегов office=notary против 860 lawyer=notary. Разумеется, после выхода новой версии JOSM первый график рванул вверх, а второй замедлился. На этот момент первый ещё не вырвался вперёд: у нас 925 office и 1020 lawyer. Росту способствовала и короткая вики-страница тега, которую, не разобравшись, создал Math1985. Он даже не упомянул альтернативный тег.

Ошибка налицо, в январе этого года я решил её исправить, создав тикет в JOSM на замену тега в заготовках. Увы, это непросто: подошёл человек из Бразилии и рассказал, что там нотариусы не являются юристами. Klumbumbus подхватил его мысль, предложив, если что-то не нравится, пройти в рассылку tagging@. Железный аргумент, фиг оспоришь. А остановки — не дороги, почему они в highway? Или почему аптеки — amenity, когда там торгуют?

Другими словами, название тега и значение тега — разные вещи. BushmanK целый год по-всякому объясняет это в своём дневнике. Проблема здесь не в обозначении, а в двух тегах для одного и того же. Благодаря бездумному копированию из таблиц, оба набора тегов теперь используются примерно одинаковое количество раз. Именно это я хочу исправить: давайте выберем один и будем его придерживаться. И у office=notary нет никаких преимуществ, кроме присутствия в заготовках JOSM.

Борьба продолжается: я только что написал в рассылку tagging@ и не ожидаю, что все её читатели легко согласятся. Впереди, наверное, и пропозалы, и голосования. Тем временем, влияние JOSM на статистику должно ослабнуть. Не потому, что началась дискуссия. А потому что в редакторе iD в субботу тоже добавили пресет для нотариуса. С правильными тегами.

Ещё одно отношение маршрутов

10 ноября 2015, 1:27

Пол Джонсон в рассылках tagging@ и talk@ обратил внимание на тег ref=* на дорогах. Ещё со времён API 0.5, в котором не было отношений, им объединяли дороги в сети маршрутов. При этом нет простого способа проверить связность такой сети; несколько маршрутов на отрезке требуют точек с запятой, которые сложно обрабатываются; и легко смешать номера маршрутов и номера дорог, где они различаются. Зачем, когда у нас уже восемь лет как есть отношения, в частности — route=road. Пол предлагает за год повсеместно внедрить это отношение, и на картах отображать номера из отношений, а не из тега ref.

Одним из первых возражений была невозможность в osm2pgsql взять атрибуты для линии из содержащего её отношения, на что выдали контрпример с американскими магистралями. Ричард Велти замечает, что для длинных маршрутов они создают супер-отношения, которые использовать сложнее — но иначе маршрут не загрузить в редактор. И конфликтов не оберёшься. А Komяpa в твитере таинственно намекнул, что выходить за пределы рамок OGC Simple Features чревато.

Затем упомянули сложность редактирования и слежения: одно дело, когда через дорогу проходят десять маршрутов, другое — всего одно число в ref, ради которого раскочегаривать редактор напряжно, да и следить, чтобы отношение не поломали, лениво (а когда ломают последовательность ref, это, видимо, не так мозолит глаз). Пол гневно возразил, что это проблема редакторов, а не людей, и Ричард, автор Potlatch, тут же попросил его умерить пыл. И привёл пример местных веломаршрутов: с ними всё в порядке, вот только новички постоянно создают копии и копии копий, потому что не видят, что отношения маршрутов уже есть.

В целом, задача не выглядит сложной, главное — людей переубедить. В talk@ дискуссия получилась куда короче: «а, ну ок». Но ключевыми людьми в сценарии перехода означены авторы картостиля, а у них и так тикетов невпроворот. Да ещё и перезаливка базы требуется. Правда, её хотят перезалить так и так, потому что для стиля критически не хватает новых тегов, и нужен hstore с их полным комплектом.

Рисование домов

23 августа 2014, 11:08

Хотя обычно дома рисовать очень просто — прямоугольник с building=yes, — на практике постоянно всплывают какие-то сложности. Danidin9, автор картинок про дома в Петербурге, наглядно объясняет (полные версии — по клику):

И пример от Felis Pimeja:

Рисование домов переменной этажности обсуждается в большой теме на форуме, некоторые теги объяснены на этой вики-странице. Не забывайте отмечать подъезды точками entrance=*.

Картируй, что видишь

21 мая 2014, 10:56

Или вот, как обозначать на карте подразумеваемые ограничения скорости? То есть, видя знак «начало населённого пункта», писать на карте не «60 км/ч» — там же нет такого знака, — а прямо «ограничение скорости в населённых пунктах». Опытные мапперы сразу вспомнят значения «RU:urban» и «RU:rural». Сможете вспомнить, в какие теги они записываются?

Румынский (и с некоторых пор — русский) подход: прямо в maxspeed. А в теге source:maxspeed указать источник. Что именно? Для знаков — понятно, «sign». А со второй строчки в TagInfo начинается каша: ограничения «DE:urban» и т. п., значения «implicit» (его советуют в пару к подразумеваемым ограничениями в maxspeed), «survey», «unposted», «national»... Поди разберись. В Австралии всё опять поставили с ног на голову и заполняют maxspeed:source. Англичане выбрали какой-то левый тег для такий ограничений: maxspeed:type. Ну и немцы с французами подливают масла бессмысленно отдельным тегом для зон.

Примерно такова у нас ситуация с обозначением всех нетривиальных свойств: материала зданий, угловых адресов, полос на дорогах, тротуаров, внутриквартального озеленения, дворовых проездов, и т.д, и т. п. Механизм пропозалов и флейм в рассылке tagging@ лишили участников удобства авторитарного решения, а вики — статуса последней инстанции в выборе правильного тега. Страницы вики полнятся спорами и попытками собрать разные теги в единую схему (вот для ограничений скорости), а потребители данных (в том числе ITO, авторы великолепного набора визуализаций ITO Map) вынуждены писать длинные рефераты и копаться в Taginfo, чтобы результат их работы имел какой-то смысл.

Что касается ограничений скорости, в России принято писать maxspeed=<число>/signals/RU:зона + source:maxspeed=sign/implicit. Расставляйте ограничения, они важны.

За мосты и электричество

26 сентября 2013, 17:19

До 6 октября можно отдать голос за два многолетних пропозала. Первый — про подстанции: power=station и power=sub_station объединяются в новый power=substation, для которого можно указать тип, местоположение и вольтаж. Из обсуждения пропозала вы узнаете, что GIS — это подстанции с элегазовой изоляцией. На сегодня тегов substation всего 79, часть из которых мои, а обоих «устаревающих» вместе — почти 140 тысяч.

Объектов со значениями тега bridge=*, отличными от yes, которые вводит пропозал про типы мостов, почти 40 тысяч. Фотографии для каждого значения делают выбор элементарным, и глядя на пропозал, удивляешься, почему его принимают только сейчас. Даже в Петербурге, известном своими мостами, последние тегированы просто как bridge=yes — а будут bridge=movable, bridge:movable=bascule, bridge:structure=*.

Есть ещё третье голосование, кардинально отличающееся от этих двух: за landuse=plot allotments=plot. Человек зарегистрировался 17 сентября, в тот же день набросал пропозал и написал о нём в tagging@, через три дня запустил голосование, которое планирует закрыть до конца месяца. Он также добавил упоминание нового тега на страницу landuse=allotments, что заметил Dinamik, сразу дополнивший список многострадальным boundary=lot, которых, оказывается, в базе почти полторы тысячи, и ещё 685 — необъяснимых lot=*.

За дороги и электричество

29 мая 2013, 14:24

Позавчера открыли голосование за пропозал, вводящий новый тег power=plant для обозначения электростанций, и слегка корректирующий требования к тегированию power=generator. В частности, добавляется тег generator:type для более детальной классификации генераторов энергии. Страница весит 50 килобайт (и ещё 35 — обсуждение), но большую её часть занимают примеры и классификация. Отдать голос можно до 10 июня.

Спорные предложения переименования sub_station в substation, уточнения схемы тегирования подстанций и их компонентов и перевода тега power=station в устаревшие вынесены в отдельный пропозал (с сорокадвухкилобайтным обсуждением). Я был неправ в февральской заметке: трансформаторные подстанции останутся substation с дополнительным тегом substation=distribution. Пропозал хорошо проработан и щедро иллюстрирован, этап RFC начался неделю назад.

Также со вчерашнего дня мапперы голосуют за отношение through_route, указывающее направление главной дороги на перекрёстках, где это не очевидно. Автор дал лишь один пример, из которого не совсем ясно, что главная цель этого пропозала — указать, где навигатор должен требовать поворота, даже если на карте маршрут выглядит как прямой. Полезный пропозал, но, как замечают многие проголосовавшие «за», требует развёрнутых пояснений.

Для обозначения приоритета главной дороги, кстати, можно применять тег priority_road со значениями designated или yes_unposted (зависит от наличия перекрёстков со второстепенными дорогами после знака). В России, как ни удивительно, этот тег используется ноль раз.

Детский микромаппинг

22 февраля 2013, 16:52

Вы же не думали, что детские площадки достаточно обвести контуром leisure=playground, и двигаться к следующему объекту? Весной 2011 года страница тега обновилась в соответствии с принятым годом раньше пропозалом, но подробности не попали в русский перевод до сих пор. Помимо обычных amenity=bench, barrier=fence, natural=tree, существует тег playground=*, которым можно обозначить качели, горку, песочницу, и даже размеченные «классики».

Немец Autsi1996 недавно написал гид по тегированию площадок, но на немецком языке. Особенное внимание он, почему-то, уделяет роутингу до площадок и неполноте стандартного картостиля по части тегов playground. Список последних на его странице отличается от принятого, и, видимо, лучше отражает реальность.

Ужасы адресации в Украине

21 января 2013, 21:30

В украинском разделе форума всплыла тема с адресацией домов по району, а не улице. Российское сообщество в этом случае использует addr:suburb, но в Украине принята схема адресации отношениями. По ней на дом ставится только addr:housenumber, затем дома добавляются в отношение типа street вместе с улицей. Dimonster составил более-менее подробное описание схемы с учётом двойной адресации и прочих необычных случаев. Так, второй адрес должен ставиться на точку внутри дома, которая войдёт в отношение street соответствующей улицы. В случае адресации по микрорайону в отношении отсутствуют члены с ролью street, что, по мнению dimonster, не важно.

Одной из главных причин использования отношений стали двуязычные названия почти всех улиц. Перенос названия улицы в отношение упростит обработку данных после «языковых войн», периодически вспыхивающих в Крыму и окрестностях. Кроме того, устраняется избыточность: название улицы достаточно написать дважды, на линии и в отношении. Украинское сообщество (или liosha), почему-то, не считает тег name идентификатором: так, для адресации по улицам с названиями на нескольких языках они (до ввода отношений) предлагали расставлять на домах addr:street:uk, addr:street:ru и т. п.

Эта схема тегирования используется не на всей территории Украины (например, не здесь), и озадачивает сделанные в России валидаторы: сайт контроля качества для Ситигида жалуется на почти двадцать тысяч неуказанных улиц в адресах. Однако свежая версия лёшиного конвертера в MP схему понимает, поэтому поиск в выгрузках для Навитела и Гармина работает. Наверное, именно поэтому, в отличие от белорусской схемы, эта смогла выжить и распространиться.

Ход конём

17 декабря 2012, 17:42

За три с половиной месяца с прошлого объявления о новой версии редактора JOSM почти ничего не произошло: только правились ошибки да пополнялись пресеты. Первого августа американец Тоби Мюррей предложил: «а давайте при загрузке данных на сервер автоматически удалять лишние теги TIGER!» И все согласились, с 3 сентября редактор начал вырезать не только created_by и некоторые tiger:* , но и odbl=* (которые к тому времени стали неактуальны). Разумеется, он трогает только изменённые и созданные объекты.

22 ноября Дирк продолжил мысль: «у нас уже есть вырезалка лишних тегов. А в базе плодятся левые схемы тегирования и опечатки. Давайте сделаем автокоррекцию!» На этот раз соглашаться было некому: Дирк — главный по редактору. Поэтому с сегодняшнего утра josm-latest втихую заменяет:
  • ключ color на colour;
  • highway=ford на ford=yes;
  • highway=stile на barrier=stile;
  • значения oneway=1/0/true/false на yes/no;
  • type=multipolygon на type=boundary в отношениях с тегом boundary=administrative.
За списком можно следить в исходном коде модуля автозамены. Подозреваю, не успеет закончиться год, как в нём появится злосчастный building=entrance .

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

13 декабря 2012, 11:52

Недавно 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@ сталкиваются с непониманием и страхом: вдруг откажут? По-моему, это — первый признак того, что вопрос перехода на новую схему вообще не стоит (а не «я выбираю первый вариант»), и что проблема «неактуальной тягомотины» надумана и раздута, не столько ради этой конкретной замены, сколько для оправдания будущих масштабных актов наведения порядка в базе.
Ctrl +  Ранее