Рабочая группа администраторов втихую работает:

• Возобновили публикацию логов просмотра тайлов. Это текстовые файлы, где написано, какие тайлы сколько раз за день смотрели. Обновления сломались в декабре, когда закрыли проект Tile CDN, переведя кэш тайлов на провайдера Fastly. Да, того самого, что обвалился месяц назад. Под настойчивыми напоминаниями Дорофея, чей проект Disaster Ninja обрабатывает эти логи, Пол Норман переписал скрипт обработки, и первый новый файл сегодня появился на сайте.
• Наконец-то сайт поддерживает авторизацию через OAuth2! Это тот же протокол, что используют Github, Strava, Twitter, Google и Вконтакте. Очень долго в приложения приходилось впиливать библиотеки для устаревшего OAuth 1.0a только для входа через OSM. Теперь всё проще, спасибо Тому Хьюзу и Mmd, разработчику CgiMap.
• К двум дата-центрам в Лондоне и одному в Амстердаме потихоньку собирают четвёртый — в Дублине. Который всё ещё в Евросоюзе, в отличие от. Новому дата-центру закупают всё, что есть в других: серверы для базы API, планеты, рендерера, номинатима и даже новый сервер для разработки. Прошлому уже десять лет, на нём становится тесновато.

Совет OSMF тоже работает, и в этом месяце умудрился попасть на первую страницу The Guardian. Поводом стало письмо Гильёма Ришара в рассылку osmf-talk, в котором он поделился желанием Совета перенести регистрацию компании OpenStreetMap Foundation из Кембриджа в Великобритании куда-нибудь в Евросоюз.

Среди причин — новые (и старые) сложности с банковскими операциями и Paypal, больше авторитета в Евросоюзе, простота найма людей из ЕС (как Доротея), и шанс зарегистрироваться некоммерческой организацией и экономить на налогах. Кроме того, с 1 июля право на базы данных (как копирайт, но на базы) разделилось между ЕС и Великобританией, и они не признают права друг друга. Лицензия ODbL работает лучше, когда есть основа в виде прав на БД, и лучше иметь их на крупнейшем рынке.

Участники обсуждения накидали предложений: Эстонию, потому что э-государство, Данию, потому что там неплохо работала Мозилла, Германию, потому что там KDE и TDF (делают LibreOffice), Женеву, с отдельно стоящим зданием или без, и Ирландию, где прячутся от налогов Microsoft, Google и Amazon. Не все страны подходят под необычные требования OSMF, но они обсуждаемы. Тема на многие месяцы — вступайте в OSMF и присоединяйтесь к заполнению таблички по странам.

Напомню, что с прошлого августа можно стать членом Фонда OpenStreetMap совершенно бесплатно. Для этого нужно просто чаще править карту: 42 дней в год достаточно. Уточните своё количество на How Did You Contribute и заполните форму на сайте вступления в OSMF. Нам нужно больше русских участников: у нашей страны худшее соотношение количества картографов и количества членов OSMF.

Две недели назад появился новый способ скачать огромные (от полусотни гигабайт) файлы планеты: через торренты. Все файлы в каталогах planet и pbf — выгрузки в bzip2 и pbf, полная история и пакеты правок — сопровождаются ссылками на файлы torrent, которые легко открыть в µTorrent или Transmission. Советую забыть про прямые ссылки и качать планету только так.

Хотя торренты ассоциируются с пиратством, их используют ещё и для распространения крупных файлов: например, дистрибутивов Linux. В отличие от обычного скачивания с сайта, через торренты вы загружаете файл сразу с нескольких источников — среди них зачастую даже нет исходного. То есть, ваш файл планеты будет скачиваться с компьютеров тех, кто уже его скачал, а серверы OSM освободятся. Учитывая пропускную способность серверных каналов и нередкие ограничения трафика, скачивать через торренты обычно быстрее, чем напрямую.

Сайт planet.osm.org встречает предупреждением, что скорость ограничена четырьмя мегабайтами в секунду: скачивание планеты в pbf должно занять четыре часа. На практике — дольше: запросы на крупные файлы отправляются на вспомогательный сервер gwdg.de. В эксперименте он отдавал файл на 100-300 килобайтах в секунду, так что расчётное время скачивания превышало двое суток. Впору поискать пиратку.

Кристиан Квест из французского OSM занялся торрентизацией планеты в январе этого года. Как он объяснил в анонсе, файл торрента создаётся через пару часов после публикации планеты, и затем данные раскладываются по нескольким серверам. Также подключается функция web seed, доступная в некоторых клиентах, с помощью которой исходные файлы тоже становятся частью сети. Всё это позволяет скачать планету за полчаса — а через пару дней, когда скачавших прибывает, можно управиться и за 15 минут.

Ограничение скорости на нашем сервере ввели в том же январе. Причиной была узость канала: всего гигабит в секунду. Обычные 30-60 одновременных скачиваний планеты забивали его так, что начинали сыпаться другие сервисы, включая DNS и API. Тогда скорость порезали до 400 кБ/с, а в феврале, когда канал расширили до десяти гигабит, ограничение ослабили. Но проблема с тысячью скачивавших каждый файл планеты сразу после его публикации (четверть из них — в формате bz2) осталась: зачем, когда есть диффы? И как ослабить нагрузку на сервер, чтобы не мешать нормальным людям?

Чтобы не зависеть от французского сервера и ускорить создание торрента, весь процесс нужно было перенести на сервер OSMF. Этим Грант Слейтер занимался с августа. Оказалось, что торренты делал ещё и Матия Налис из Хорватии: его скрипты легли в основу официальных. 23 ноября торренты появились в списке файлов сервера, и несколько дней спустя они охватили и дампы с полной историей. Теперь пора и нам переключиться на скачивание торрентов вместо прямых ссылок.

Как видно, инфраструктура OSM не стоит на месте: новые технологии, пусть и с десятилетней задержкой, приходят на наши серверы. Что дальше? Репликация. Диффы сейчас создаются программой Osmosis. Два года назад её автор Бретт заявил, что хватит с него, программе 11 лет и есть другие варианты. Обновлять базу теперь можно с PyOsmium (пример для тайлов), а вот создавать диффы из живой базы — увы. Osmosis использовал какую-то устаревшую магию, заменить которую безуспешно пытаются с 2017 года. Но решение, кажется, появилось: Йохен Топф летом написал замену, и две недели назад началось тестирование новых диффов. Когда основные ошибки отловят, Osmosis окончательно выкинут с серверов. Пока же Майк Мигурски подхватил его поддержку и время от времени выпускает заплатки.

На прошлой неделе 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 даже выглядят приятно: например, форум смоленских байкеров. Айан Диз уже смог импортировать базу форума на новый движок и сейчас исследует, как перенести учётные записи пользователей.

Что это я всё хвалю 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 всегда увлекательно.