Данные без базы
Michal Migurski уже месяц работает над избавлением картографов от необходимости ставить PostgreSQL, импортировать планету и настраивать репликацию: вместо этого он предлагает задействовать плагин к Python Datasource для мапника, скачивающий данные тайлами в бинарном формате MVT (Mapnik Vector Tiles). Позавчера он делал доклад на конференции GeoMeetup, где упомянул, что сервер тайлов уже работает. Он выдаёт четыре слоя — дороги, их названия, землепользование и водоёмы. Испытав свой плагин, Michal заметил, что большая времени уходит на скачивание тайла: впрочем, едва ли кто оставит этот источник данных после отладки стиля.
Впервые тему векторных тайлов поднял OJW пять лет назад. Изначально он хотел выдавать куски OSM по запросу: в то время планета весила в семь раз меньше, и это можно было считать разумным. В 2011 году идею разрезания данных на квадраты оживили в OSMT — но ненадолго, на пару дней. Единственным проектом, который использует тайлы не в формате json, остался OpenScienceMap: картографическое приложение для Android непонятного назначения. И ещё у Cloudmade есть тайлы в SVG: когда-то, наверное, этот формат считался перспективной заменой растровым.
Самыми известными векторными тайлами остаются GeoJSON-тайлы для Kothic JS: написав в 2011 году их рендерер на JavaScript, Komяpa качественно удивил сообщество. Увы, несмотря на оптимизм программистов, плодами работы стали лишь зависшие багрепорты для основных браузеров, несколько слайдов, демонстрирующих мощь русскоязычных программистов, и генератор тайлов, написанный в рамках Google Summer of Code прошлого года. Месяц назад, после долгого перерыва, гитхабовские репозитории сервера и библиотеки неожиданно активизировались: возможно, мы всё-таки увидим настоящий проект на основе Kothic JS.
Впервые тему векторных тайлов поднял OJW пять лет назад. Изначально он хотел выдавать куски OSM по запросу: в то время планета весила в семь раз меньше, и это можно было считать разумным. В 2011 году идею разрезания данных на квадраты оживили в OSMT — но ненадолго, на пару дней. Единственным проектом, который использует тайлы не в формате json, остался OpenScienceMap: картографическое приложение для Android непонятного назначения. И ещё у Cloudmade есть тайлы в SVG: когда-то, наверное, этот формат считался перспективной заменой растровым.
Самыми известными векторными тайлами остаются GeoJSON-тайлы для Kothic JS: написав в 2011 году их рендерер на JavaScript, Komяpa качественно удивил сообщество. Увы, несмотря на оптимизм программистов, плодами работы стали лишь зависшие багрепорты для основных браузеров, несколько слайдов, демонстрирующих мощь русскоязычных программистов, и генератор тайлов, написанный в рамках Google Summer of Code прошлого года. Месяц назад, после долгого перерыва, гитхабовские репозитории сервера и библиотеки неожиданно активизировались: возможно, мы всё-таки увидим настоящий проект на основе Kothic JS.
Очень жаль, что примеру не последовали остальные браузеры, и особо обидно за багрепорт в адрес IE10, закрытый Microsoft как CONFIRMED/WONTFIX.
Но вот то, что Mapnik требует PostgreSql считаю безобразием, вполне можно иметь python скрипт создающий sqlitedb из выбранно pbf и позволяющий работать Mapnik. В основном от мапника требуются стили и сервер, база данных — это как один из.
Еще один формат MVT, имхо не нужен.
sqlite, mysql или как его модно стало называть mariadb и прочие какбы-базы-данных — это утопия, если речь идёт о работе с геопространственными данными. Хранить плейлист аудиоплеера или закладки браузера — вот и весь удел sqlite. Я ещё соглашусь, что работать с ними возможно быстрее, но отнюдь не проще, если речь идёт о выборке в пару мегабайт, но тоже пространство бывшего СССР за пару лет в pbf выросло с 500 МБ уже до полутора гигабайт и я думаю порог в 2 ГБ мы преодолеем ещё к осени.
А что касается самого «нового» векторного формата, то это только ещё одна прослойка, отнюдь не тривиальная в установке и добавляющая головной боли и в идеале ну совсем никак не коррелирующая с бакэндом, хранящим пространственные примитивы.
Виктор
На счет sqlite. Если вы в sqlite планируете хранить данные осм как есть, точки, веи ссылающиеся на линии и отношения ссылающиеся на что угодно, то любому приложению которое попытается по таким данным что то быстро рисовать поплохеет. Если же подразумевается что дамп sqlite содержит уже готовую геометрию, то генерация такого дампа это не быстро и не просто. Ну точнее или быстро или просто.
В общем-то здесь есть непонимание, если мы рассуждаем о сайтах с показом карты всего мира, то тут postgresql нормально, настраиваешь и работаешь.
Но если мы говорим о Mapnik для того, чтобы протестировать рендеринг локально, настроить что-то, показать друзьям, то тут он вполне может работать со встроенное и настраиваемой БД. В плане запустил Mapnik, указал папку с obf-файлами, а он уже встроенную БД или сервер подтянул.
Благо встроенных БД полно (не нравится sqlit, firebird возьмите).
К тому же ваша фраза «R-tree индексы в sqlite достаточно быстрые штуки просто его надо уметь настроить» сводит на нет само использование sqlite, т. к. нет разницы какую DB придётся настраивать, всё равно надо настраивать.
Повторюсь: не должен рендер работать конвертором pbf (osm, om5) в любой другой формат, а потом сам же поднимать экземпляр базы в этом формате и использовать его. Это не задача рендера, это задача стороннего софта. Напишите утилиту osm2sqlite по аналогии с osm2pgsql и используйте её в скриптах по своему усмотрению, а к мапнику нужно только дописать коннектор для ещё одной DB.
>> На батниках и визуалбейсике!
ЗЫ: Могу посодействовать XD
1. Причем здесь остановка роста частоты процессоров?
2. Чем osm-xml, отдаваемый osm-api, не векторные тайлы?
Но что будет, если я попрошу z1? что я получу, 27 Гиг вектора?
Основное свойства тайла — иметь ограниченный размер, вне зависимости от масштаба.
В случае растровых тайлов это достигается автоматически. Даже если я исхитрюсь отрендерить береговую линию всего мира из 100500000 отрезков, все равно объем тайла не сможет превысить 196 кб (256*256*3)
Для векторных «тайлов» встает вопрос об отборе и _упрощении_ геометрии (генерализации). Отсюда и в докладе слайд про Natural Earth. Это самый напрашивающийся путь. z18-z11 — осм, z10-z1 — что то другое, не осм.