ШТОСМ

Конец SVN

На прошлой неделе SVN-репозиторий кода OpenStreetMap перевели в режим «только чтение». Чуть раньше то же сделали с Trac, системой управления задачами и онлайн-интерфейсом к коду. Оба сервиса давно устарели, разработка давно перешла в Git. Кроме JMapViewer и модулей для JOSM, которые переехали на собственный сервер.

Trac и SVN — это концентрированная история нашего проекта. Там можно посмотреть на первый код Стива Коста от августа 2004 года, когда он начал строить API на языке Java (потом всё переписали, конечно). В репозитории можно найти Osmarender и Tiles@Home, Gosmore, Yours, зачатки Mapnik и Nominatim, Potlatch 1, форк JOSM без инструментов, старый Java-аплет и много маленьких полезных скриптов для импорта и работы с данными. Большинство проектов переехали на GitHub. Ничто, кроме модулей JOSM, не обновлялось с 2018 года. Тикеты в Trac тоже перестали появляться полтора года назад, теперь их только закрывают.

Несмотря на медленный поток новый версий, и Trac, и SVN для современных разработчиков мертвы. Их успешно заменяют GitHub, GitLab или Bitbucket. Последняя версия Ubuntu, на которую сейчас переводят серверы OSM, вообще исключила Trac из репозиториев, отчасти потому, что тот требует устаревшего Python 2.7. Проекты OSGeo, когда-то все на Trac, переходят на GitHub или Gitea. Неудивительно, что в мае рабочая группа OWG решила отключить эти сервисы, оставив для истории их замороженные слепки.

Что делать разработчикам модулей для JOSM, которые пользовались SVN: зайти в каталог репозитория и ввести svn relocate со ссылкой из этой страницы. Дальше работать как раньше, через svn ci, svn up и тому подобное. В ближайшие годы JOSM не слезет с SVN, пусть код уже зеркалируется на GitHub. Но учить эту систему не обязательно: новые модули можно разрабатывать в GitHub или в GitLab. Достаточно создать проект в группе JOSM и добавить ссылку на собранный jar-файл в этот список.

Это не последнее изменение, запланированное OWG. Когда-нибудь случится ещё одно, которое затронет всех без исключения активных участников проекта. Форум, почтовые рассылки и справочную систему собираются объединить на движке Discourse. Потому что нынешний движок старый и неудобный, а форумы на discourse даже выглядят приятно: например, форум смоленских байкеров. Айан Диз уже смог импортировать базу форума на новый движок и сейчас исследует, как перенести учётные записи пользователей.

Тысячи тонн картографической руды

Позавчера Microsoft выпустила новый Flight Simulator. Технически это лучший симулятор пилота в мире, современный Crysis, который тормозит на топовом оборудовании. Дамир в TJ отлично описал саму игру, Сэм в The Verge классно рассказал про её создание, а Фредерик в TechCrunch рассказал про компанию, которая делала для симулятора карту мира.

Как игра связана с OpenStreetMap? Очевидным образом: геоданных по всему миру больше взять не у кого. Но на нашей карте тоже есть белые пятна, поэтому для симулятора её дополнили зданиями и прочими объектами, распознанными из двух петабайтов снимков Bing. Три года назад мы ещё удивлялись, зачем им столько бесполезных снимков ненаселённых мест, — теперь ясно.

Поскольку оценить качество полутора миллиардов зданий невозможно и приходится полагаться на участников OSM, игроки находят в мире игры забавные аномалии. То башню в частном секторе из-за пропущенного building:levels=212, то неуместно современную застройку, то неевклидов ужас вместо Бергена. В видео пролёта по Москве река неспокойна: её воды местами поднимаются на уровень третьих этажей.

Из открытых источников собирают мир и в симуляторе X-Plane, ещё с десятой версии 2011 года. Его авторы тоже сталкивались с проблемами, ещё до того, как это стало модно. Но у X-Plane карту мира не продают, там важны только точность моделей и аэропортов. Подумаешь, мост в реку провалился. Данные в этом симуляторе можно обновить, заново подгрузив их из OSM. Все понимают, что они вторичны, пусть и очень хороши.

Generation Streets позиционируется как визуализатор OSM и пост-апокалиптик, поэтому и провалившиеся мосты, и переулки на 26 полос нормальны. А проблемы типа этой важны — их исправляют

MSFS же начался с карты. Microsoft ставит точность и детализацию мира во главу рекламной кампании. Слетайте в свой город. Приземлитесь где угодно. Петабайты, нейросети, облака — всё, чтобы на экране было то же, что за окном. Гигантский масштаб работы порождал экзистенциальные комиксы, и хотелось увидеть: неужели произойдёт чудо? На высоте 10 км для симуляции достаточно спутниковых снимков, на 1 км — простейшей их коррекции на высоты. Но будет ли опыт пролёта между домами более впечатляющим, чем аналогичный опыт в Apple Maps или Google Earth VR?

Да, конечно же, ответ — да. Все замеченные проблемы как будто несистемны: где-то необычные здания классифицированы как обычные, где-то не сложились рельеф и застройка, где-то просочились ошибки из OpenStreetMap. Это можно понять и простить. Но от проекта, за которым стоит команда Bing и ресурсы Microsoft, ждёшь большего внимания к деталям. Мы смотрим на картинки и такие «а, ну да». Недочёты не только понятны — они предсказуемы. Для людей, знакомых с OpenStreetMap.

Крупные компании нанимают осмеров, чтобы помочь с использованием данных проекта и с общением с сообществом. Это похвально и правильно. Но если честно, любой человек с рациональным, структурным мышлением может понять, как устроен OSM, что можно и что нельзя. Осмеры не нужны: достаточно картографов-технарей. Но чего последние не смогут предвидеть, так это того, что мы видим на скриншотах Flight Simulator. Потенциальные проблемы. Крайние случаи. Неявные классификации.

Если вы провели в OpenStreetMap долгое время, вы полезнее для любой компании, работающей с геоданными, как опытный программист полезнее индийского фрилансера. Просто потому, что видите не только общую картину, но и знаете, что может пойти не так, чтобы заранее это учесть. Нейросети могут предсказать очевидное, но визуализацию карты оценивают не по среднему, а по исключениям: достопримечательностям, сложным развязкам, знакомым местам. Понятно, что за два года разработки невозможно отловить ошибки никаким QA. Но был бы хоть один осмер в штате компании — и мир Flight Simulator был бы чуть правоподобнее.

Право на POI

Торговые центры — досадные белые пятна на нашей карте: в них слишком много магазинов. Обычная практика — пройти мимо всех, сфотографировать и записать данные, а потом отрисовать, — для ТЦ не работает, потому что это не одно-два заведения на здание, а сотня-две. Целый день убить на один дом! Поэтому в городе может быть десять магазинов The Body Shop, но вы не найдёте в OpenStreetMap ни одного, потому что все они в торговых центрах, которые лень обходить.

Помня об этом, позавчера я посидел часик и отрисовал две трети магазинов в рижском ТЦ Spice, пользуясь буклетом со схемой, стащенной из этого центра. Порадовался, как удобно это в iD, и почувствовал, как приношу пользу будущим пользователям карты. Прямо захотелось ещё нагуглить схем торговых центров и щедро рассыпать POI по Риге и Минску. К чёрту схемы помещений, были бы сами магазины.

Меня остановил Павел Гаврилов:

Я правильно понимаю, что этот пакет изменений надо откатывать, потому что у нас нет ЯВНОГО разрешения использовать данные с этой коммерческой карты? Аргумент «я там ходил, поэтому имею право перерисовывать чужую карту» с Гуглом и Яндексом почему-то не принимается.

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

Чем эта аргументация отличается от срисовывания адресов с карты Яндекса, когда контуры зданий уже есть в OpenStreetMap? Проезжали деревню, видели несколько адресов, с яндексом совпадают. Технически это даже не копирование данных: смотрим числа, запоминаем, расставляем на карте уже по памяти.

В нашем проекте есть юридическое слепое пятно, о котором мы стараемся не задумываться: можно ли использовать рекламные и информационные стенды и буклеты для уточнения OpenStreetMap?

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

Присутствовать на картах важно для всех. Поэтому магазины, компании, торговые комплексы сами идут к 2ГИС, яндексу или посредникам, чтобы их можно было найти. За четыре дня до меня в тот ТЦ зашла «рокетдата», добавив в случайные координаты внутри здания аптеку. Аптека заплатила компании, чтобы появиться в OpenStreetMap. Откажется ли ТЦ от того, чтобы кто-то бесплатно перенёс их план на карту, которую используют примерно все? Разве что из подозрительности: обычно это стоит больших денег; бесплатное картирование бывает только в мышеловке.

Сложно понять, где кончается ground truth и начинается копирование чужих данных. Отметить «пятёрочку» по фотографии, не зайдя внутрь и не убедившись, что это продуктовый магазин, нормально? А натолкнуться на дверь с двумя десятками плашек всяких адвокатов и турфирм, не открыть её и внести всё это в OSM? Нарушает ли это права владельца этого бизнес-центра? Прощёлкать панорамы улицы и добавить на карту все POI, что видны на фотографиях, нарушает авторское право фотографа? Можно ли, взяв визитку с адресами филиалов турфирмы, закартировать их?

Фотография © mapfool, Mapillary, CC-BY-SA

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

Эти требования кажутся смешными, но обоснования ответов на них определяют будущее OpenStreetMap. Мы уже более-менее разобрались с рисованием геометрически протяжённых объектов: дорог, лесов, городов. С адресами всё тоже более-менее ясно. Есть крупные источники геоданных, которые чаще всего нельзя использовать, есть государственные и открытые данные, есть снимки. Одно разрешение открывает геоданные целого города или страны, поэтому мы продолжаем писать запросы. Ответили отрицательно — не беда, возьмём другие источники или снимки. У нас есть выбор.

Для заведений выбора нет. Никаких крупных баз, которые потенциально могут разрешить использование. Либо обходить ногами и записывать, либо просить миллион разрешений от миллиона источников, в каждом до сотни заведений. Что делать — выделить шкаф для складирования ответов? Или перечитать законы и пересмотреть условия использования информационных материалов?

POI не могут ждать. Дороги пролежат десятки лет и их названия не изменятся, деревни тоже дождутся заблудшего картографа. Рано или поздно мы нарисуем административные границы и все велодорожки, поэтому нет смысла спешить, подключать нейросети и тырить данные из крупных ГИС. Но в случае заведений политика ожидания не работает. Салоны красоты появляются и исчезают; приходит вирус — и торговые центры вычищаются; наносить магазин за углом бесполезно, когда весь квартал ходит в этот магазин уже десять лет.

Легко делать самую актуальную карту в контексте развязок и новостроек, сложнее следить за свежестью магазинов в ближайшем ТЦ. Муторно и трудно увидеть своими глазами и записать все заведения в своём районе, невозможно повторить такой обход во второй, в третий раз. Сообщество OSM с подозрением смотрит на импорты и не уверено, что можно использовать любые сторонние материалы, от списка адресов на сайте компании до плана эвакуации на стене. Даже приложения, которые позволяют добавлять заведения любому, кто проходит мимо, не устраивают многих осмеров. Может ли с такими ограничениями наш проект быть надёжной картой не только улиц, но и заведений?

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

Гонка за JSON

Что это я всё хвалю iD — у него тоже проблем хватает («ахаха» — раздаётся от жосмера в голове). Например, Саймон Пул четыре дня назад заметил, что в некоторых регионах данные не подгружаются, без причин и без ошибок. Какие-то слова про undefined в консоли, и всё.

Позавчера Квинси понял, что выпадают объекты, нарисованные анонимными пользователями до 2009 года. У этих объектов нет поля uid, чего редактор не ожидал. Но тогда вопрос, почему раньше этой пропажи никто не замечал? Ответ — в JSON.

Мало кто любит XML. Это структурированный формат, который может хранить любую структуру данных, но слишком многословен и требует сложных преобразований. С популярностью JavaScript разработчики предпочитают использовать другой формат хранения данных, JSON (JavaScript Object Notation). Формат жёстко регламентирован, но по сути, представляет собой кусок кода, который интерпретатор JS может быстро превратить в объект. Сюрпризов у него никаких, структура очевидная для программистов, в отличие от XML, поэтому формат пихают везде: например, вам может быть знаком GeoJSON.

OSM API всегда отвечал в формате XML. Но в сентябре 2018 года cgimap научился возвращать ответ в формате json. Для этого в запросе нужно указать правильный заголовок Accept или добавить в конец расширение .json (например). Одним из первых новому формату научился важнейший запрос /map (получение всех данных в прямоугольнике), затем пошли остальные. Но, поскольку формат ещё не поддерживал Rails Port (часть API, написанная на Ruby on Rails), json временно отключили.

Разрыв нужно было закрывать: участник Mmd в мае 2019 года сделал пул-реквест в вебсайт, но мы знаем, как у нас проходят пул-реквесты. Второй пул-реквест он создал в декабре. Он был проще, обсуждение сразу пошло: всего через полсотни комментариев, в феврале, правки приняли, и теперь объекты можно получать в любом из двух форматов.

Тут все посмотрели на iD. Для кого ещё писали поддержку json, как не для редактора на JavaScript? И да, всего через неделю соответствующие вызовы заменили — поддержку нового формата тот же Mmd написал ещё год назад. Но свежий релиз редактора готовился-готовился, прошёл один месяц, второй... В общем, строчка про json утонула в списке изменений версии 2.18, вышедшей две недели назад. Отсюда и проблема, найденная Саймоном: формат ответа API поменялся, его обработка тоже, и анонимные правки забыли протестировать. Ошибку починили буквально вчера.

По замерам Mmd, использование json для скачивания данных ускорило iD примерно вдвое. Перемещение карты в редакторе действительно ощущается быстрее, контрастируя с заторможенным интерфейсом редактирования тегов.

Подгрузку данных в редакторе ещё можно ускорить, и даже в несколько раз. Сам запрос /map невыносимо медленный: сервер делает несколько запросов к базе данных на каждый объект в ответе, что, как посчитал Дорофей «Komяpa», ограничивает скорость получения данных до примерно 2000 объектов в секунду. Именно поэтому iD разрешает редактирование от 16 уровня масштаба, а не дальше. В 2016 году Дорофей переписал запрос к карте на чистый SQL, ускорив его на порядок, но его предложение погрязло в комментариях, а после добавления формата json и вовсе устарело. То есть, мы знаем, что скачивание данных можно ускорить, но для поддержки быстрого кода нужны знания PostgreSQL, которых нет ни у кого из админов.

Обновление: Mmd в комментариях замечает, что запрос /map переписали в 2018 году, ускорив его даже лучше, чем это сделал Дорофей. Так что последний абзац уже неактуален.

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

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

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

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

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

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

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

Ранее Ctrl + ↓

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