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

теги

Залив не залить

Файлы и отображение береговой линии в OpenStreetMap не обновлялись между 9 января и 25 июля, более полугода. Никто этого не заметил, потому что активные осмеры давно уточнили свои берега и обращают внимание на другие, сухопутные объекты. JesseFW описал, что произошло, и Кристофф докинул интересных ссылок и объяснений в комментариях. Если коротко:

  • Береговые линии собирает отдельная группа людей, не те, кто делает картостиль или администрирует серверы OSM. Это немцы внутри организации FOSSGIS, в частности Йохен Топф.
  • Скрипт сборки работает автоматически, но перед публикацией делает простые проверки собранных полигонов. Например, что геометрия не имеет самопересечений, или что размер суши изменился не более, чем на 0,15 км².
  • Если валидатор заявил об ошибке, новые полигоны нужно одобрить вручную, либо пойти исправить ошибку.
  • В январе кто-то перерисовал залив Rio de la Plata рядом с Буэнос-Айресом с береговой линии на озеро (или наоборот). Йохен не знал, что с этим делать, и оставил полигоны без изменений.
  • Через три месяца отсутствие обновлений заметили, но даже откатить это изменение, чтобы применились остальные, было поздно: сумма изменений давно переросла площадь отсечки.
  • Все ссорились ещё три месяца.
  • Вчера Йохен плюнул и одобрил свежую сборку.

Проблема залива сводится к тому, что считать его внутренним морем удобно для разграничения территории между Аргентиной и Уругваем, но если natural=coastline отодвинут, то Буэнос-Айрес получается совсем не прибрежным городом. Стороны привлекают аргументы типа солёности воды, приливов и спутниковых снимков (как в заголовке этой статьи). Обычная политика, какой много в мире и в проекте. Но интересна проблема с выгрузкой береговой линии тем, что она подчёркивает, как близки в OpenStreetMap технические и идеологические решения.

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

Даже не поднимая голову от клавиатуры, занимаясь только кодом и перегоном одних букв в другие, в OpenStreetMap не избежать политики. Ведь политика появляется там, где сталкиваются интересы двух людей с одинаковыми ресурсами, а в OSM нет модераторов и потому все равны. Взяв на себя работу проверять, что линии не пересекаются, однажды обнаруживаешь, что не можешь нажать кнопку, потому что любое решение огорчит десяток картографов. Внезапно обнаруживаешь себя в центре политического спора, и хочется бросить всё и подождать, пока рассосётся само.

В идеальной базе геоданных территории не принадлежат нескольким государствам одновременно, озёра и леса не накрывают одни и те же поляны, названия всегда распределены по языкам и однозначны, а атрибуты не дублируются на точках и полигонах. Любая дискуссия быстро заканчивается резолюцией управляющего органа: рисуем так, а не иначе. К такому идеалу стремится НЯК, но никак не может его достичь. Идеальную карту скучно рисовать. Именно из-за недосказанностей и рекомендаций вместо правил в OpenStreetMap всегда увлекательно.

 2 комментария   2 мес   osm.org   теги

Стиль виляет картографами

В середине февраля Matthijs Melissen, один из разработчиков стиля osm-carto, предложил улучшить отображение административных границ на далёких масштабах. Пул-реквест не только перекрашивает границы в тёмно-зелёный цвет, но и приглушает эти линии на воде. Посмотрите на результат на этой карте.

Поскольку изменения оказались велики, их решили разбить на части: первая затрагивает только водные границы. Под примерами отображения Matthijs добавил комментарий: «поскольку тег admin_level отсутствует на некоторых линиях границ, потребуется немного покартировать».

Долгое время стиль отражал схемы тегирования: рисовал всё больше и больше значков, разделял или объединял отображение дорог в зависимости от дополнительных атрибутов. Немало было и спорных решений: например, объединение highway=footway и highway=path. Но те решения следовали правилам тегирования, а не требовали что-то в них менять.

На этот раз не так: предлагаемые изменения требуют добавления тегов boundary и admin_level не только на отношения границ, но и на линии в их составе. Конечно, мы часто так и делали, но это не было обязательным. Теперь отсутствие тегов должно было сломать границы стран и регионов на всех масштабах, от самого первого. И поскольку это вопрос тегирования, Matthijs-у пришлось написать в рассылку tagging@.

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

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

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

Если кто-то хочет ввести в вики 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 в субботу тоже добавили пресет для нотариуса. С правильными тегами.

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

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

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

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

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

 3 комментария   2015   теги

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

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

Здесь придётся дорисовать building:part, потому что объект с building=yes не отображается:

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

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

2014   теги
Ранее Ctrl + ↓

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