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

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

Он был и есть прямо сейчас в 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, но надо поработать с ним.

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

В quad tree применяется техника наложения обычно, 0.55 коэфициент, поэтому все линии закончатся зумом 11 не больше. С другой стороны наложение - это очевидная дубликация данных. Вопрос если мы делаем файл только для чтения и процессинга, дубликация данных не страшна, для редактирование это уже критичнее.

Hadoop я бы не использовал. Слишком сложен в настройке и если решение остается закрытым и не предоставляет открытого API, то как черная коробка ничем не отличается от Postgresql.

Если мы обсуждаем bitcoin blockchain, то наша скорость известная 40МБ osm.gz в день, причем >50% идет на нарост БД. То есть если хранить всю историю правок vs снепшот последнего, то разница не такая критичная предполагаю раза в 3 больше. В Биткоине блок составляет 0.6МБ и их происходит около 144 в день, т.е. размер около 100 МБ в день, что сравнимо c OSM.

Дак а причем тут биткоин и блокчейн? Биткоин это distributed hash table + цепочка подписей.
Писать свой DHT? Тут куча вопросов как это написать и без разработки своего алгоритма DHT сети. И без DHT есть сомнения что это кто-то в бозримом будущем реализует, а если еще и самим кластеризацию колхозить - это не взлетит никогда.

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

Я про то, что получается овер-размер всех этих тайлов-данных.
Вот тут будет 3 Гб

А на зум ниже будет 2Гб, но опять тех же самых данных.

Всё локти кусаю где код подсмотреть, видимо никогда:

http://link.springer.com/chapter/10.1007%2F978-3-642-38562-9_16 ST-HBase: A Scalable Data Management System for Massive Geo-tagged Objects

freeExec объект записывается в тайл наименьшего размера (наибольшего зума) в который может быть записан полностью.

Тогда надо ограничиваться каким нибудь 10 зумом, да и то получим необходимость хранить 100500 этих тайлов для всех данных, это явный минус против одного.

Почему?

…одного тайла-переростка который никто не запрашивает кроме как раз в 8 лет или при быстром передёргивании карты в пару секунд.

Все смотрят города и POI на 17-22 зумах, а не леса на 2-4 зуме.

В чём “явный минус” 100500 тайлов не понял:

  • детальные логи доступа, хорошая статистика
  • более гибкие рамки что и куда хранить, а не “либо этот тайл 2,4 ГБ либо соседний тайл 3,4 ГБ”

Инфраструктура для 100500 файлов решается файловыми системами, не нужно их переписывать.