{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "ШТОСМ: заметки с тегом api", "_rss_description": "ШТОСМ", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/shtosm.ru\/tags\/api\/", "feed_url": "https:\/\/shtosm.ru\/tags\/api\/json\/", "icon": false, "author": { "name": "Илья Зверев", "url": "https:\/\/shtosm.ru\/", "avatar": false }, "items": [ { "id": "1546", "url": "https:\/\/shtosm.ru\/all\/milliard\/", "title": "Миллиард", "content_html": "

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

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

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

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

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

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

Так что решение — не мешок побольше, а постоянная поддержка. Заходить раз в пару лет в репозиторий и проверять, что предположения, сделанные годы назад, ещё верны. Жаль, что в мире открытых исходников популярность не означает денег на поддержку, и некоторые инструменты устаревают просто потому, что некому поменять несколько букв в исходном коде.<\/p>\n", "date_published": "2021-11-07T15:59:13+04:00", "date_modified": "2021-11-07T15:58:55+04:00", "_date_published_rfc2822": "Sun, 07 Nov 2021 15:59:13 +0400", "_rss_guid_is_permalink": "false", "_rss_guid": "1546", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "1503", "url": "https:\/\/shtosm.ru\/all\/zhelaem-togo-chto-imeem\/", "title": "Желаем того, что имеем", "content_html": "

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

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

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

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

И ещё пора перестать делать вид, что 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 ограничивают все способы работы с данными.<\/p>\n

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

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

Нам не нужно упрощать данные. Нынешние инструменты отлично справляются с преобразованием их в удобные другим людям форматы. Нам нужно подумать, чего мы лишены. И доделать это: изменить инструменты мониторинга или поправить модель данных, чтобы понять историю нашей карты.<\/p>\n", "date_published": "2019-09-27T12:29:16+04:00", "date_modified": "2019-09-30T12:22:05+04:00", "_date_published_rfc2822": "Fri, 27 Sep 2019 12:29:16 +0400", "_rss_guid_is_permalink": "false", "_rss_guid": "1503", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } } ], "_e2_version": 3576, "_e2_ua_string": "E2 (v3576; Aegea)" }