В spatialite, уж лучше. Я с ней работал, вполне норм, даже MapSurfer на него натравливал.
На самом деле, идея классная, но нужно сначала определиться с целями и ограничениями, а то можно, как тут уже происходит, в какую-то левую глушь уйти. Например, цели:
- Быстрое вырезание региона, со временем, пропорциональным размеру региона;
- Быстрое фильтрование по тегам;
- Сохранение небольших размеров диффов и простоты их накатывания;
- Возможность обновления региональных или тематических выгрузок без потери данных;
- Значительное ускорение импорта в базу osm2pgsql.
Пример ограничений:
- Не более десяти файлов для любого количества данных;
- Увеличение относительно .osm.bz2 не более, чем в два раза;
- Создание диффов из минутного osc не более, чем за 20 секунд на пятидолларовом сервере DO;
- Простая машиночитаемая структура (не сложнее o5m, но можно бинарник).
В процессе реализации окажется, что всё это не выполнить, но 7 из 9, например, уже будет неплохо.
Хороший способ, это выделять issues.
- Работает, точно так же как быстро вырезать из planet.sqlite или файловой системы растровых тайлов, тайлы относящиеся к одному региону. На ФС работает очень быстро, так как имена файлов считаются в памяти, а копирование всегда линейно по кол-ву файлов и по размеру.
- Реализуемо. Я предлагаю делать софайлы - индексы, которая может утилита быть. Примеры приведу ниже.
- Размер дифов, можно сохранить как есть сейчас не увеличивая размер в 2-3 раза.
- Возможность обновления региональных или тематических выгрузок. Учтена “изначальна”, правда применение утилиты будет необходимо, чтобы из “общего” дифа, сделать специфический.
- Предлагаю от этого пункта отказаться и использовать mapnik прямо на файлах, mapnik вполне может так работать и это будет совсем немедленно, зачитав osm.gz в некоторую in memory db, скормить его stylesheet и забрать тайл. Это решает задачу скачал и сразу начал рендерить тайлы безо всякого ожидания. Скорость рендеринга тайлов технически реализуема на том же уровне. Нюанс находится на тайлах низкой детализации, нужно искать приемлимое решение. Уже сейчас рендеринг тайлов 6-9 зума может занимать до 3-4 минут на очень быстром сервере.
- Про кол-во файлов, не согласен. Современные файловые системы отлично справляются . Понятно что все можно собрать в zip или sqlite или zipfs, но это уже детали реализации. Идея которой я придерживаюсь, тайлы должны быть файлами, т.е. потенциально для планеты их может быть столько же, сколько тайлов 15 зума существует (естественно океан нам не нужен
), существуют очень много способов как собрать файловую систему в один файл. - Про размер. Надо мерять
- Имеется в виду не создание дифов, а применение дифов. Это момент я пропущу. Как я писал выше, нужно менять osc (а точнее его дополнять) иначе ничего не получится. Я сознательно выделяю моменты, где требуется хоть что-то менять на центральных серверах или реализовывать на доп. серверах.
- Структура только text! Потому что text файлы удобнее изучать, удобнее искать ошибки и все могут открыть в текстовом редакторе . Программы оставим binary, а данные text
Мы тут просто обсуждали две разные вещи:
- полная замена API (это ещё про репликацию и масштабирование вопрос)
- выгрузка которая будет удобна для большинства задач (попроще)
Название темы не помогает определиться. Выгрузку будем мастерить или заново апи?
Речь только о хранении данных, преобразовании файла планеты в более удобный формат.
Я думаю, сумбур надо разобрать. Изначально я хотел обсуждать только новый формат данных! Но я сразу предполагал, что придется хоть чуть-чуть, но поменять API, к примеру формат OSMC, поэтому дописал API.
Предлагаю тему переименовать в: Новый формат выгрузок на основе OSM XML и возможные изменения API связанные с ним.
Предлагаю ознакомиться с текстовым индексом:
https://dl.dropboxusercontent.com/u/286774/map_index.zip (osm.xml, + index.txt - 431KB zip)
https://dl.dropboxusercontent.com/u/286774/map.osm.zip (osm.xml - 428KB zip)
Утилитка готовая есть, единственное, что не работает - это subtiles, там они наугад проставлены. Текстовый файл составлен таким образом, что имея 4 subtiles text index, можно построить parent text index. Имея, такой общий индекс и зная теги можно построить поиск по имени (что-то наподобие адресного поиска) и поиск по type (поиск POI).
Не понял, это индекс или просто статистика.
Как это мне поможет найти объект?
{texttag:'man_made', unique:'3', freq:'3', subtiles: {4,15}}
{texttagvalue:'man_made', index:'point', freq:'1', unique:'1', subtiles: {4,18}}
{texttagvalue:'man_made', index:'survey', freq:'1', unique:'1', subtiles: {4,18}}
{texttagvalue:'man_made', index:'tower', freq:'1', unique:'1', subtiles: {4,18}}
{texttagvalue:'man_made', index:'water', freq:'1', unique:'1', subtiles: {4,18}}
{texttagvalue:'man_made', index:'well', freq:'1', unique:'1', subtiles: {4,18}}
По тегу находится в каких subtiles оно лежит, затем можно зайти в “папку 4”, открыть osm.xml и найти его. Сами конечные тайлы достаточно маленькие, чтобы их можно открыть в текстовом редакторе и найти объект. Это древовидный индекс + немного статистики.
Я не понимаю, зачем возможность ручного поиска. Какие задачи она решает? Кто в своём уме руками будет высматривать все highway=level_crossing на планете? Или запоминать координаты bbox для ограничения запроса?
И если ограничиваться тайлами, то либо они будут конского размера (несколько мегабайт) и включать в себя половину тегов из индекса каждый (кроме океанов), либо они будут сильно мелкие, что приведёт к дубликации данных и к конского размера спискам субтайлов в индексе.
Я бы взял за основу тайлы o5m с внутренней разбивкой на подтайлы и ссылками внутри файла.
Индекс по тегам - тупо не нужен.
Выборку по редкому тегу можно получить из того-же оверпаса, для частой комбинации - всеравно придется пробежать все тайлы из набора.
Вообще, если геометрия уже построена, то фильтрация по тегам делается в 1 проход и без использования большого числа оперативки. А вот выгрузок с собранными линиями (полигонами, мультиполигонами и т.д.) - нет.
А текстовые форматы - это удобно, хош сортируй, хош грепай, хош - конкатенируй.
Только вместо JSON - XML. Потому что не хочется CSS переписывать на выборки из этого json.
Либо у нас так много пользователей json? Откуда он прёт, какой смысл есть за ним?
Думаю, нужен, но не по всем. Проблема оверпасса в том, что он не работает в офлайне, сложно настраивается, требует адского количества ресурсов при установке, и ненадёжен. А здесь мы просто берём файл и обрабатываем. У меня, например, частая задача — выделить из планеты костлайны или адм. границы.
Тогда, может, на OPL обратить внимание? Правда, они, пока что, write-only для программ.
Xml (если генерить 1 большой документ) плох тем что его неудобно склеивать, неудобно сортировать объекты внутри файла.
xpath на документах нашего размера начинает очень натужно работать.
Да OPL только я не понимаю зачем выдумывать свой формат для записи объекта в строке, завернуть его в json (ну или в xml, только не генерить 1 огромный документ а в каждой строке держать 1 объектик заэнкоженый в xml). Это не столь уж и важно (для меня) json или xml. Но лучше что-то стандартное. Чтоб свой не писать свои граматики и парсер.
Если геометрия уже построена, то все админ. границы и/или все коастлайны фильтруются из планеты в один проход.
Вообще можно это в мамбле обсудить, только чур не в 23мск.
Тут явно не упомянули (вернее, не повторили с открывающего поста), но разбивка на тайлы полезна тем, что результат можно обрабатывать многопоточно.
Проблема с XML в том, что это большая стена текста, которую медленно обрабатываться просто из-за ограничений по i/o. В сравнении с бинарными форматами — на порядок (в ~10 раз) медленнее.
Ну можно геометрию как hex WKTB записывать чтоб поменьше места занимала. Если текст выровнен по страничкам и можно его просто в память мапить кусками то работает это оч. быстро.
o5m я кстати предлагал сделать блочным, чтоб ожно было грузить его страничками. Но при маленькой страничке, мы не шибко то и выйграем, т.к. основная эконоия у o5m имхо за счет “таблички” строк.
У нас для всего есть тулы, но кто может вспомнить сколько мы ждали overpass (3 года?), сколько мы мучались с taginfo, что нельзя было найти, где же находится этот тег с багом.
OPL как формат мне нравится больше JSON, но опять же у индекса нет задачи показывать все объекты и геометрию, это всего лишь индекс для поиска (help формат). Поэтому это не замена индекс-файлу. Заменять osm.xml на opl, идея хорошая, но может не такая необходимая.
Разбивка по тайлам, построение индекса, агреггация индекса для супертайла только из индексов подтайлов, может за разумное время дать текстовый индекс для большой страны, если имеются индексы на самих тайлах. Для меня выглядит поважнее.
Насчет индекс-файла, это всего лишь представление, если он подходит под некоторые задачи это замечательно, если нет можно добавить или сделать другой индекс файл, но не убавить - нет смысла, пусть будет
Откуда этот посыл взялся? Я как раз везде пытаюсь писать, что все файлы должны быть маленькие не больше 3-5 МБ, чтобы удобно открывать и обрабатывать было! Как добиться большего объема, точно так же как мы делаем для тайлов, раскладывая по папки. Если файл маленький то принципиально нет разницы, что там и даже чем обрабатывать (XML, JSON, OPL). Текстовые файлы для чтения людьми, поэтому важно, чтобы читалось удобно.
Не по хорошему мил, а по милому хорош.
Кто будет делать, тот и выберет формат.
Вообще в o5m есть и ресеты и прямые ссылки где начинается точки, линии, отношения. Т.е. сделать страницы по 64к вообще не проблема.