Пока готовился к докладу, прослушал много попыток представить 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. А затем и соответствующие кнопочки на сайт.

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