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

теги

Тропинки

Идёшь, значит, по лесу, смотришь ягоды по сторонам, гладишь случайного кота. Заглядываешь в Organic Maps и замечаешь, что тропинка не отмечена. Вечером открываешь JOSM, проклацываешь линию — и вспоминаешь, что когда в прошлый раз навесил на тропинку привычный тег highway=path, набежали другие мапперы и завязался спор. Как же правильно?

Довольно долго был консенсус: highway=footway — это пешеходная дорожка, за которой следят (улучшают покрытие, устанавливают освещение и т. п.), а highway=path — это случайная тропинка, типа как люди протаптывают на углах между footway или в лесу. Год назад это было отмечено и в русской вики. Разница казалась очевидной: по path не всегда проберёшься на велосипеде, а footway вполне подходит. Объединение этих тегов на картостиле OSM Carto стало той гранью, за которой некоторые участники разочаровались в его принципах. «Path и footway — совершенно разные объекты по OSM Wiki» — писал vvoovv. Откуда недопонимание?

Оказалось, англоязычное сообщество ещё в 2013 году поспорило на эту тему, почти ровно десять лет назад. Ричард пожаловался в дневничке, что path обозначает «всё вышеперечисленное»: и тропинки, и велопроезды, и грунтовки, с покрытием и без. Никто не знает, что там под path. Шон из Cyclestreets сдаётся: «чёрт его знает, что там». Швед Туре для своего картостиля пытается выжать максимум из дополнительных тегов, но что делать, если их нет? В нашей вики с 2009 года собирают мнения о path, и единственное, на чём сошлись, — четырёхколёсные транспортные средства туда либо не поместятся, либо запрещены.

Как же тегировать правильно? И почему у нас есть нормальный простой тег для пешеходных дорожек, но нет тега для тропинок, которых гораздо больше?

Триединые теги

Простой ответ — такой тег есть, и это highway=path, только указывайте surface и bicycle. Сложный требует понимания трёх уровней access: физического («тут можно проехать»), юридического («тут разрешено проехать») и онтологического («это тротуар»). Первые два из них отмечаются одним тегом (access/foot/bicycle/bus/motorcar/...). Хотя в вики юридический аспект выделен и несколько раз просят не использовать тег для физических ограничений, кто из нас не навешивал access=no на закрытые ворота, или motorcar=no, когда на проезжей части бетонный блок?

Онтологическое ограничение доступа выводится из других тегов и географического контекста — например, highway=footway. В России мы знаем, что по тротуару юридически нельзя ехать на велосипеде, но физически — вполне. Поэтому иногда переключаем планировщик маршрутов в режим пешехода, чтобы построить лучший веломаршрут. А тот, в свою очередь, подключает highway=path в болоте и делает маршрут интереснее.

У нас есть теги highway для всего. Path возникает, когда дорога проваливается сквозь классификации:

  1. Одновременно пешеходная и велосипедная дорожка, или ещё какие-то равнозначные категории. Можно, конечно, выбрать главную и сделать highway=cycleway + foot=designated (т. е. пешеходам знаками тоже разрешено). Но вики и JOSM советуют уравнять их через highway=path + нужное проставить в designated. В этом случае path — это шаблон для footway, cycleway, bridleway и прочих; highway=path + foot=designated = highway=footway.
  2. Дорога без назначения. Здесь ходят грибники или ездят квадроциклисты. Или пропахал осенью джип, тренируясь к заезду. Маршрутов для четырёхколёсных средств нет (иначе бы поставили highway=track или highway=service), но следы налицо. Иногда такие дороги облагораживают, от чего они не перестают быть path.
  3. Ничья дорога. То, что мы называем тропинками. Все остальные значения highway стоят на учёте, эта же возникла стихийно и не зарастает только потому, что там ходят или ездят люди. Покрытие натуральное. Отличие от 2 — тропинка может куда-то вести или быть важной частью велопешеходной сети. Там «не используется, чтобы куда-то добраться», здесь — «не стоит на балансе».

Все три пункта объединяет то, что мы не можем ничего сказать про проходимость path для кого-либо, кроме здоровых пешеходов. Ну, разве что тег bicycle=* поможет. Поэтому для highway=path обязателен хотя бы один дополнительный тег. Да, это surface. Он дополняет 29% path в мире, но 22% в России.

Path недостаточно

Помимо surface, для городских дорожек стоит указать тег юридического доступа (foot=designated) вместе с segregated=yes/no для велопешеходных дорожек. Как ни странно, мапперы ставят footway=sidewalk/crossing и на highway=path: звучит странно, но по первому пункту вверху разницы никакой. Впрочем, и вики, и тагинфо допускают path=crossing.

Загородные и парковые тропинки различаются по проходимости. Её нужно отметить чем-то из этого:

  • Тегом физического доступа bicycle=yes/no. Не совсем легально, но в некоторых случаях альтернативы нет. И гарантированно поможет планировщикам маршрутов.
  • smoothness, хотя он слишком заточен под автомобили (тропинки — very_bad и ниже). Я бы использовал surface:grade.
  • informal=yes для всех «ничьих» дорог, третий тип в списке выше.
  • trailblazed=yes, если по ходу тропинки на деревьях есть отметки.
  • sac_scale для горных троп, trail_visibility для ориентирования, mtb:scale для техничности прохода на велосипеде, wheelchair и width — кажется, уже перебор.

Но главное, что вытекает из первого пункта классификации выше, — тропинки можно отметить как highway=footway! Этот тег подразумевает foot=yes/designated, то есть:

  1. По footway гарантированно можно пройти, он создан, чтобы ходить. При этом для велосипеда разрешение не очевидно: тег bicycle за городом обязателен. В остальном же правила такие же, как для path: добавляйте surface и остальное.
  2. Можно напороться на аргумент, как для highway=cycleway в Петербурге: ставим тег только на тротуары и дорожки, обозначенные знаками 4.5.1-4.5.5. То есть, footway обозначает юридический статус дорожки. Всё остальное — игристый path.

Подытоживая, в OpenStreetMap всё сложно, и прочитав тридцать вкладок, я не стал понимать систему лучше — даже не нашёл никакой системы. Сейчас я бы картировал лесную тропинку с фотографии как highway=footway + surface=ground + bicycle=yes. Что поменялось — раньше я смотрел на тег highway=path и видел тропинку, на которую лучше не соваться на велосипеде. Теперь я вижу тег-заглушку, который не имеет смысла без пояснений. Чего и добивались авторы роутеров и картостилей.

 10 комментариев   4 мес   теги

Микромаппинг улиц

Photo by Dario Ayala /Montreal Gazette

Как вы знаете, линии highway в осме нужно нещадно резать. Изменилось количество полос? Остановка запрещена? Пунктирная разделительная сменилась сплошной? Появилась стрелочка «прямо или направо»? Началось место для парковки? Режем и расставляем теги.

Когда я год назад уточнял по панорамам улицы в своём районе, я быстро наткнулся на проблемы такого подхода. Например, parking:lane:*:capacity — количество мест. Звучит разумно, пока с другой стороны дороги не меняются полосы, и дорогу не нужно разбивать прямо по парковке. И пересчитывать capacity. А если на улице ещё есть велополоса, то микромаппинг становится совсем изнурительным.

Об этом в 2019 году писала Эмили из команды SharedStreets. Они занимались картированием условий вдоль тротуаров: разрешений на остановку и стоянку, мест для разгрузки, и тому подобного. В Северной Америке любят понаставить знаков — и наслаивающиеся теги ограничений на линиях улиц начинают угрожающе трещать. Страшно двигать точки, того и гляди, сломаешь.

Для решения предложили мапить ограничения косвенно, через знаки. Ставишь для знака точку со всеми нужными тегами, при желании связываешь с внешней базой. Когда приложению нужно узнать, что там с парковкой, оно проецирует эти точки на улицы и вычисляет применимые ограничения. Сразу понятна сторона улицы, и двигать геометрию не так страшно. Примерно так у нас картируют знаки «уступите дорогу»: недалеко от перекрёстка, чтобы было понятно, к чему относятся.

Увы, предложенный в статье тег никак не продвигали, и taginfo не может найти ни одного примера. Кто знает — идея разделить геометрию и атрибутику не так плоха. Может быть, мы бы и запреты обгона бы сейчас картировали через расположение знаков, а точек traffic_sign=city_limit хватило бы для неявного ограничения скорости в населённых пунктах.

Резать незачем

Год назад Алексу Сайделу (Supaplex030 в осме) понадобилось посчитать парковочные места в берлинском районе Нойкёльне. Для этого он разметил его весь (по снимкам, конечно) тегами parking:lane=*. Обработав данные в QGIS и посчитав отношение количества мест к зарегистрированным автомобилям, он сделал наглядную картинку. Для нас же важно то, как именно он рисовал эти места.

Он не отлавливал знаки на панорамах и не отмерял метры, чтобы поставить теги ровно на нужные отрезки дорог. Он не добавлял числа в capacity. Если посмотреть на район в OSM, удивляет, что свойства парковок стоят на целиковых отрезках от перекрёстка до перекрёстка. Алекс же в своём скрипте предобработки вырезает пять метров до перекрёстков, 15 м до автобусных остановок и прочие препятствия, а затем считает, сколько машин поместится с выбранным видом парковки (например, перпендикулярным).

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

Не остановиться

Почуствовав мощь предобработки и похожесть отрисованной карты на спутниковый снимок, Алекс продолжил. Как правильно показать велодорожки? Можно связать их с улицей через cycleway=lane и дополнительно описать в тегах bicycle:lanes и предложенном cycleway:separation. Несложно нарисовать стрелочки на полосах из значений turn:lanes.

Где этому предел? OpenStreetMap бесконечно глубок: можно мапить люки и уличные фонари. Автор выгреб из тегов и геометрии почти всё возможное. Особенно впечатлило, как он рисовал полосы вокруг островков безопасности: две линии проезжих частей превращал в один визуальный объект. А сам островок детально отрисовывал полигоном traffic_calming=island.

И это, конечно, микромапинг. Для нужного уровня детализации он оказался неизбежен. Всплыли и полигоны area:highway, которые не совсем про картографию. С их помощью отрисовываются стоп-линии на перекрёстках. А машинки вдоль дорог примыкают к поребрикам barrier=kerb. На эти линии предобработка полагается во многом — но, например, когда я вижу их в Москве, я вздыхаю и предпочитаю не смотреть. Ведь абсолютная практическая точность данных OSM не ниже полуметра и сопоставлять поребрики с другими объектами, часто нарисованными по разным источникам, больно.

Превосходство предобработки

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

Обработав OSM и наложив сверху немного местных открытых данных, Дастин Карлино сделал гениальный инструмент для дорожного планирования, симулятор трафика A/B Street. Машинки и велосипедисты ездят по правильным полосам, создают пробки, паркуются где надо. Даже и не скажешь, что это та же карта, что и у Mapbox, где одна линия на экране для дороги — уже достижение. Про A/B Street автор рассказал на SotM 2021, в том числе и про главную его проблему — отсутствие пользователей.

Когда в Maps.Me мне предложили вытащить из OSM данные для прокладки маршрутов через метро, я понимал невозможность задачи. Но формализация правил плюс предобработка — и навигация в двухстах городах у нас в кармане. Следующим шагом была бы навигация по остальному общественному транспорту, но я слишком выгорел, чтобы выдвинуть на голосование универсальную транспортную схему.

Профессиональное использование OpenStreetMap — это не только знание тегов и региональных особенностей. Это и умение правильно спланировать работу с данными, чтобы не нагрузить ни картографов, ни тайловый сервер. Предобработка — именно то волшебство, которое возносит данные OSM над коммерческими. Мы много говорим, что наша модель данных лучше других свободой в тегировании. Эта свобода требует знаний, алгоритмов и вычислительных ресурсов. Сложно. Но лучше несвободы.

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

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

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

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

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

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

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

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

Ранее Ctrl + ↓

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