Миллиард

Илья Зверев — Sun, 07 Nov 2021 15:59:13 +0400

Аманда обратила внимание, что в субботу американский картограф залил в базу линию с круглым номером — 1 000 000 000.

Практического смысла в таких событиях нет, зато это повод отметить рост OpenStreetMap. Как в феврале можно было отпраздновать стамиллионный пакет правок, в апреле — точку 2³³, а скоро мы увидим десятимиллиардную точку.

Таких ошибок, как восемь лет назад, когда номера точек перевалили за 32-битный лимит, и многие приложения сломались, мы уже не допускаем. Или..? Что произойдёт через пару лет, когда номера линий тоже выйдут за 2³², требуя другого типа данных для их хранения? Когда чинили типы для точек, все ли попутно увеличили лимит для линий?

Некоторые готовятся уже сегодня. Например, Overpass API. В нём есть отдельный тип данных, area (области). Его идентификаторы генерируются из идентификатора линий или отношений, добавлением фиксированного очень большого числа. Но что выглядело большим десять лет назад, теперь пугающе близко к настоящим номерам. Для линий выделено окошко всего в 1,2 миллиарда значений. В следующем году нумерация area на замкнутых линиях в Overpass API начнёт пересекаться с областями на отношениях.

В версии 0.7.57 Overpass API, вышедшей в октябре, такая нумерация областей больше не поддерживается. Автор переписал обработку замкнутых линий, и теперь нужно пользоваться либо запросами на поиск области по названию и местоположению, либо кодом way(1234567); map_to_area;.

Хитрости с числами рано или поздно выходят боком. Вспомним проблему 2000 или даты в GPS. Хочется сказать: не делайте так. Но такие оптимизации помогают сделать алгоритмы быстрее и уменьшить их требования к памяти. Аккуратное отношение к типам данных помогло, например, когда-то запихнуть движок OSRM внутрь мобильного приложения MAPS.ME.

Так что решение — не мешок побольше, а постоянная поддержка. Заходить раз в пару лет в репозиторий и проверять, что предположения, сделанные годы назад, ещё верны. Жаль, что в мире открытых исходников популярность не означает денег на поддержку, и некоторые инструменты устаревают просто потому, что некому поменять несколько букв в исходном коде.

Желаем того, что имеем

Илья Зверев — Fri, 27 Sep 2019 12:29:16 +0400

Пока готовился к докладу, прослушал много попыток представить API 0.7 другими людьми, особенно Йохеном Топфом и Энди Алланом. И прочитал, конечно, страницу в вики. Предложений много. Самые радикальные, но с которыми сложно не согласиться, проходят по разряду «наша модель данных сложная, давайте приблизим её к Simple Features». Специальный тип для полигонов, например. Но правильно ли мы хотим?

У нас же всё есть. Мы уже умеем отличать закрытые линии от периметров, умеем разбирать мультиполигоны. Зачем упрощать, когда незачем упрощать? То же самое в предложении Йохена убрать точки без тегов и добавить линиям координаты — по сути, собственную геометрию. Да, сейчас кэширование координат ест память, собирать объекты неудобно. Но кто сказал, что должно быть удобно потребителям данных? Удобно должно быть редакторам, потому что OpenStreetMap — проект для редакторов. С их позиции всё отлично: тайлы рендерятся, данные в базу загружаются, osmium вообще быстрый стал.

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

Разумеется, API всё равно устарел и его нужно менять. Только смотреть не туда, куда показывают натруженные пальцы программистов. А туда, где болит конкретно у вас, картографов. Вандалы замучали? Давайте думать, что нам упростит поиск проблемных правок и их откат. Лень тратить время на исправление тупых ошибок вроде линий из одной точки? Посмотрим, какую валидацию можно встроить в обработчики загрузки данных. Не выбрать между landuse=forest и natural=wood? Давайте запретим один из них на уровне API.

И ещё пора перестать делать вид, что Overpass API — сторонний проект, никак не связанный с OSM API. На минуточку, в вики более сорока страниц про первый и всего одна про второй. OSM API не находится в вакууме, это интерфейс доступа к данным не лучше и не хуже других. Поскольку OSM децентрализован, то ничего удивительного, что API разбросан не только по нескольким странам, но и по нескольким способам доступа. Overpass API — один из них, и он решает очень много пожеланий к API 0.7. У него одна проблема: в отличие от Taginfo, Nominatim или форума он не установлен на серверах OSMF, и поэтому его сложно воспринимать всерьёз участникам проекта. Даже несмотря на то, что сервисов, написанных на Overpass, больше, чем использующих API. Ваш API 0.7 — это Overpass API, смиритесь с этим и думайте, какие особенности OSM API ограничивают все способы работы с данными.

Я поставлю на отказ от пакетов правок: как метаданные, они лучше расстановки одинаковых тегов на всех объектах, но не оправдывают никаких ожиданий. Запрос для скачивания содержимого пакета, а не только тегов, должен быть выкорчеван из API, чтобы не подавать странных идей. И поставлю на лучшие связность и версионирование: не могу не согласиться с Йохеном, что когда внутри одной версии у линии может быть несколько разных геометрий, это дезавуирует всю систему версионирования. Нельзя откатить линию или отношение к прошлой версии, потому что это вызывает вопросы, к каким версиям откатывать их члены. Так мы возвращаемся к API 0.5, когда история адресовалась по меткам времени. Поэтому специфику OSM, «всё связано со всем», нужно подчеркнуть указанием ссылок на родительские элементы, и версии делать либо составными, либо увеличивать на каждый чих.

В докладе на State of the Map, помимо проблем комментариев к правкам, я упомянул, что неплохо бы добавить способ выкачивания полной истории для любого объекта, включая историю его членов. И получение удалённых объектов для заданной области. Которое у нас уже есть для Potlatch 1, но не для остальных редакторов, несмотря на попытки Фредерика. Да, это частично умеет Overpass API, но работа с исходной базой данных поможет получить результат быстрее и помочь в выкапывании истории другим инструментам, которые не приняли Overpass как нашего отца и спасителя. Наконец, задумавшись об истории в API, мы сможем сделать ещё один маленький шажок и добавить в него метод /revert. А затем и соответствующие кнопочки на сайт.

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

ШТОСМ: заметки с тегом api

Миллиард

Желаем того, что имеем