В основном это для просмотра комментариев в истории/просмотра тегов которые у объекта сейчас. Т.е. можно кешировать до какой-то разумной степени.
Те кто не любят историю смотреть ничего не заметят, а те кто будет вникать почему что менялось могут остаться без инструментов.
С другой стороны комментарии можно сделать к тайлам?! Но тогда потеряется связь объектами которые комментируют. Это важно при правке скажем админ-границ, чтобы в истории линий добавлялись нужные комментарии.
Я не рассчитываю что такой способ хранения заменит механизм на котором основан 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, но надо поработать с ним.
Как так не много, что домики целиком в тайл не помещаются 
В 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 тайлов не понял:
Инфраструктура для 100500 файлов решается файловыми системами, не нужно их переписывать.
Ну дальше эти 100500 файликов пакуются в 1 зип, и вроде все счастливы.
Смотреть картинки мы и сейчас можем. А вот чтобы обработать данные придётся иметь все тайлы, чтобы найти границу России скажем.
Для всех задач сразу и с голубой каёмочкой не оптимизируешь.
Админ границы - нужны вроде бы всем разработчикам.
POI, детали городов - нужны миллионам пользователей “поверх” разработчиков
Логичнее что для “только админ границ” сделать отдельный специальный сервис. Я забыл ссылку прямо сейчас есть немецкий сервис выгрузки шейпфайлов по admin_level. Там даже интрерфейс с деревом и галочками для скачивания сделали.
На самом деле самый просматриваемый по количеству тайлов зум это 17, 18 - в разы меньше, 19 смотрят единицы, но возможно если бы адреса начинались с 16, то статистика была бы немного другой. Стоит учитывать что тайлов 17 вчетверо больше чем 16, а просмотров больше процентов на 30, это я к тому что количество тайлов растёт быстрее чем количество просмотров на зум. Статистика тайлов с osm.org ограничивается 0-19 зумами.
Допустим 17 сейчас самый популярный, давайте для него в первую очередь оптимизировать.
зум пользователя зависит
Т.е. если 17-19 это один стиль, то мы должны говорить о 19 в том числе. 18 и 19 не смотрят потому что ничего нового и пользователи “привыкают” к этому.
Нужно смотреть не только статистику но и хотелки пользователей, пользователям всегда нужны POI на низких уровнях (не важно какие конкретно цифры).
кроме стиля на количество отображаемого влияет плотность точек. если на 17 зуме иконка не влезает, то ее не отображают, а на 19 вполне могут уместиться несколько иконок.