Возможные изменения в OSM xml, API

Попытаюсь ответить на критику, чтобы поддержать дискуссию, не скажу, что я однозначно предлагаю, то или иное решение, но обсуждение + и - необходимо.

1. Человекочитаемые и человекоредактируемые форматы необходимы! Postgresql - не является crowdsource проектом. Такие форматы облегчают жизнь и разработку новых тулов “непрофессионалами”, они поощряют исследования. Для работы с бинарными форматами уже нужен хороший язык программирования и библиотеки и самое главное техническим людям непрограммистам придется очень непросто.
2. Если человек захочет написать любой полезный сервис на скрипте, ему надо потратить “много часов” на импорт OSM API. Если представить, что человек ограничит себя выбором только одной страны, то рано или поздно перед ним встанет вопрос масштабирования, который осуществить будет сложно. И это не считая, что сервис или утилиту придется писать используя БД. Никто не говорит, что БД это плохо, но много людей предпочитают работать с файлами, для это можно сравнить сколько идет загрузок с geofabrik, а сколько подымают локальные БД.

Я думаю основную пользу OSM приносят и будут приносить непрофессиональные картографы и непрофессиональные программисты, существование огромного числа тулов на сегодняшний день не отменяет того, что надо стремиться к лучшему.

Теперь ближе к теме, чтобы не расползаться. Давайте представим “красивую картинку” как могло бы работать с самого начала.
Planet - это некоторый большой zip или торрент с огромным списком тайловых векторных файлов. Да, да векторные тайлы. Кто хочет скачивает всю планету, кто хочет выборочно, главное, что всегда можно докачать недостающие, не нарушая работы программы и не вызывая никаких остановок.

Mapnik - это преобразовать osm.xml → image. Да это не куча запросов к БД, это просто стриминг, с очень эффективным кешем. Главное преимущество, не в том, что результат выглядит по другому, а в том, что разработка существенно проще.

Обновления приходят независимо по тайлам и обновляются они независимо. Хорошо было бы если они распространялись как торренты, плюс к этому каждое обновление ссылалось на parent (как комиты в git), тогда технология высчитывания недостающих тайлов проста.

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

OSM полностью заточен на центральные сервера, хотя distributed technologies развиваются стремительно.

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

По существу: в OSM существует только геометрия точек! Странным образом точки имеют теги. Т.е. получается, что из физической геометрии линии, мультиполигоны, полигоны, …, только точки имеют теги. Линии не имеют геометрия она вся произведена точками! Плохо получилось с полигонами, потому что они приравнялись к линиям (плохо потому что документация различает линии и полигоны, а вот картографирование нет), а с мультиполигонами вообще плохо получилось их вывели даже не через точки, а через линии.
Что плохого, что точки имеют теги? Плохо то, что работать с точками легко и просто, надобавлял точек прописал и готово. И понять легко и работать просто, хоть с текстовым файлом.
Из-за этого большинство тулов и картографов тоже, начинают использовать точки не так как хотелось бы, например, проставлять номера домов не на домах, проставлять подъезды не на домах, а внутри и т.п. Что усложняет работу другим тулам, а это значит тормозит развитие OSM в целом. Если какая-то фича трудная и ее не получается сделать хорошо в >20% продуктах, она вообще не будет картографироваться нормально!

Вернемся к геометрии точек. В принципе, это естественно, но хватает ли нам ее? Если бы геометрия нам позволяла иметь линию, точку и полигон, много задач упростилось, но возникли описанные сложности. Во-первых мультилиния, мультиполигон - по-прежнему недоступны, во-вторых непонятно как делать интеграцию между точками и линиями, как справедливо, замечено для графа дорог.

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

Скорректирую пару высказываний, без контекста у них не тот смысл.

Человекочитаемое представление - точно за.
Человекочитаемое хранение - очень спорный вопрос.

Понятно для чего это всё предлагается. Коротко прокомментирую один момент

Некорректное сравнение, я не случайно привёл ссылку на виртуальную файловую систему.

“файл” это абстрация ВФС/ФС. ВФС/ФС обычно опетирует на блочных устройствах или на “крутом” железе с нестандартной/заточеной архитектурой.

Вопрос “как хранить” это к блочным устройствам и “сегодняшним” ограничениям HDD/SSD/RAM и даже кешей проца.

Ничто не мешает написать файловую систему/API который будет представлять байтики в виде XML/TXT/GEOJSON/GIT дерева.

Просто один пример и про высказывание (“Postgresql - не является crowdsource проектом”). MYSQL не является crowdsource проектом. Wikipedia/Wikidata использует её до сих пор(?) как бекенд.

Почему mysql/postgresql?

• потому что индексы не велосипедить. Особенно PostGIS (гео-индексы это ой не простая тема, т.к. численная стабильность, топология и все дела) https://en.wikipedia.org/wiki/PostGIS#Users - не критерий для выбора бекэнда, но всё же
• потому что десятки лет тестировалось в продакшене, большими компаниями и исследователями в БД (у “монгодб” такие исследования начинаются с “обнаружена ещё одна уязвимость 0day …”).

Абсолютно верно замечено что масштабировать не просто. В отличие от той же Википедии и Wikidata они не работают с гео-данными (читай проблемы чуть выше)

Для общего развития, обзорное видео про историю разработки Neo4j: https://www.youtube.com/watch?v=Vfz–5hX5qs Neo4j Spatial - Craig Taverner

PS. на русском субтитров нет (пока)

Я вообще хочу избежать классических индексов, за счет того, что разбиение на тайлы 15 зума не предполагает их, то есть можно спокойно прочитать весь osm.gz, чтобы найти 3-буквенные анаграммы и используемые теги, на высших уровнях мы можем агрегировать низшие.
Смотрю видео про neo-4j, Quad-tree дерево решает проблему древовидного поиска, мы сразу знаем в каком тайле надо искать.

Идея понятная, но что делать с запросами которые требуют топологию отдельных объектов?

Не хочу занижать успехи Neo4j Spatial, но заявления O(1) крайне голословны когда идёт речь о IO интенсивных операциях. У жёстких дисков не бывает ответов за O(1) в принципе, у них всё в миллисекундах, в количестве операций и гарантированном времени доступа.

• нужно тестировать на реальных osm-workload (последняя неделя/месяц ченджсетов из OSM), причём кто быстрее: старый стек или новый
• нужно смотреть производительность в ms
• нужно смотреть полностью ли утилизируется железо

Да, решает. По крайней мере, в теории это всё красиво и просто. Лично мне этот вариант симпатичен, но большой вопрос подойдёт ли новая структура для всех/большинства пользователей(редакторов).

Прямо сейчас я не знаю много ли лишнего в https://github.com/neo4j-contrib/spatial и стоит ли присоединяться либо просто использовать только их разработки вместо собственных и помогать им.

Всеравно нужен индекс id <=> тайл, (osc которые генерят для планеты покамест никто не переделывал, там вроде есть BBOX но он не всегда поможет, т.к. есть правки которые покрывают сразу весь мир). Дальше надо эти индексы (quad-tree и id <=> тайл) синхронизовать.

Нет, это все конечно-же вполне возможно и реализуемо и будучи реализовано существенно упростило бы жизнь разработчикам, но что-то я не вижу толпы добровольцев.

Человекопонятность не нужна - нужен досконально документированный формат, а для ленивых библиотеки

Он был и есть прямо сейчас в OSM:

WAL лог для хранения правок
http://www.postgresql.org/docs/9.5/static/wal-reliability.html
http://www.postgresql.org/docs/9.5/static/wal-configuration.html
http://www.postgresql.org/docs/9.5/static/wal-internals.html

https://www.pgcon.org/2012/schedule/attachments/258_212_Internals%20Of%20PostgreSQL%20Wal.pdf

Для ленивых - PostgreSQL, SQL.

Будете изобретать свои структуры - потеряете репликацию и будете велосипедить WAL (минутные правки это редкая мерзость и велосипедизм).

Разница postgresql подхода и OSM подхода, у нас нет скачек PSQL базы данных. Дампы базы разрезать на тайлы еще та сложность. Если мы говорим про distributed database, то они все построены на принципе, что подключение равнозначное и точно не read-only. Самый близкий проект, как ни странно, это Bitcoin - blockchain, распределенная БД платежей. Любой качает дамп, подключается и он в строю и получает мгновенные обновления + любой “доверенный” может контрибутить обратно. Я не говорю, что это perfect match, тут явно не хватает, чтобы можно было скачать дамп некоторого региона, а не всей планеты

https://blockchain.info/charts/blocks-size - не в сжатом 43GB? как посчитать количество элементов/“правок” там?

вообще идея сумасшедшая, но четыре тайлика можно составить в биткоиновских структрурах?

Если кто-то им деньги доверяет хранить + всю историю, то почему бы там OSM не хранить? другое дело как там Quad-tree организовать?

Какие там гарантии получения полной “базы”? Если с HTTP протоколом ожидания по времени можно предсказать, то как ведёт себя blockchain?

Ну тут возможно извращение с функциональными индексами

Посмотри формат mapsforge там насколько я помню тайлы играют важную роль

Saint_Byte дак там они (тайлы) уже нарезаны. Индекс id-tile прежде всего нужен при построении геометрии линий. Потом запрсы дай мне что-то по id уже не шибко нужны…

В основном это для просмотра комментариев в истории/просмотра тегов которые у объекта сейчас. Т.е. можно кешировать до какой-то разумной степени.

Те кто не любят историю смотреть ничего не заметят, а те кто будет вникать почему что менялось могут остаться без инструментов.

С другой стороны комментарии можно сделать к тайлам?! Но тогда потеряется связь объектами которые комментируют. Это важно при правке скажем админ-границ, чтобы в истории линий добавлялись нужные комментарии.

Я не рассчитываю что такой способ хранения заменит механизм на котором основан API, в лучшем случае я расчитываю поднять реплику планеты, с данными организованными в такую структуру. Соответсвенно история и коментарии мне не нужны. Для получения истории и объекта по id у нас сервисы есть. А вот данных в формате удобном для дальнейшей бработки - нету.

Вы тайлы рассматриваете таких же уровней как и графических, т.е. тайлы 2 уровня будет иметь размер в четверть планеты?

Смотря кто мы, но как сформулировал Виктор, да тайл 2 уровня покрывает четверть планеты, но физически в него записываются лишь те линии/отношения которые полностью лежат внутри этого тайла. Тоесть таких будет немного. Основной объекм данных - это точки раскиданные по тайлам 15 (можно и 16) зума.

И я бы кое-что переделал:
Вопервых, я бы не использовал иерархичность xml’я, мне больше нравится вариант 1 строка - один объект. Закодировать его можно в xml или json.
Вовторых, бы отдельно записывал геометрию и теги. Либо проиндексировал бы точки. Тоесть тайл AAABBB представлял бы из себя папочку с файликами
node.ids node.tags
way.ids way.tags
relation.ids relation.tags
Внутри, на каждой строке, объект. Для ids содержащий лишь айдишки, метаинфу и геометрию
для tags - все целиком.
Над этим я еще подумаю, как лучше, нужен способ быстро “выдрать” id+координаты для всех точек тайла. Это понадобится для построения индекса id-tail
Для инфраструктуры под всем этим, я бы наверное взял hadoop, но надо поработать с ним.

Как так не много, что домики целиком в тайл не помещаются