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

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

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

Человекопонятность не нужна - нужен досконально документированный формат, а для ленивых библиотеки :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 этих тайлов для всех данных, это явный минус против одного.