Данные без базы

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.
Поделиться
Отправить

Мнения, высказанные на этом сайте, отражают точку зрения лично автора сайта и ничью больше: ни его бывших или настоящих работодателей, ни семьи и знакомых.

19 комментариев
Komяpa 2013
По поводу «зависших багрепортов»: котик был включён в релизные тесты Chrome, и с тех пор хром рисует его всё лучше и лучше с каждым релизом. Вот, в последних Canvas вообще сделали асинхронным, и в кои-то веки исполнение js-кода котика стало заметным в профайлере на фоне внутренних процессов браузера, которые в js-коде уже никак не пооптимизируешь :3

Очень жаль, что примеру не последовали остальные браузеры, и особо обидно за багрепорт в адрес IE10, закрытый Microsoft как CONFIRMED/WONTFIX.
Mourner 2013
Эй, а почему только Котяру и белорусских программистов упомянул? На график контрибьюторов бы посмотрел... https://github.com/kothic/kothic-js/contributors
Илья Зверев 2013
Я знаю, что ты и Miroff участвовали в разработке, но согласись, у сообщества kothic ассоциируется с Котярой :) Впрочем, заменил «белорусских» на «русскоязычных».
Виктор 2013
Насчет импортирования всей планеты со скриптами (osmconvert) считаю достаточно простой задачей и даже быстрой.
Но вот то, что Mapnik требует PostgreSql считаю безобразием, вполне можно иметь python скрипт создающий sqlitedb из выбранно pbf и позволяющий работать Mapnik. В основном от мапника требуются стили и сервер, база данных — это как один из.

Еще один формат MVT, имхо не нужен.
Maks Vasilev 2013
Вот как раз в PostgreSQL не вижу ничего плохого, в отличии от разнообразных питоньих обвязок и простыней скриптов и недоделанных утилит типа osmconvert и ему подобных, которыми обрастает процесс работы с данными ОСМ.

sqlite, mysql или как его модно стало называть mariadb и прочие какбы-базы-данных — это утопия, если речь идёт о работе с геопространственными данными. Хранить плейлист аудиоплеера или закладки браузера — вот и весь удел sqlite. Я ещё соглашусь, что работать с ними возможно быстрее, но отнюдь не проще, если речь идёт о выборке в пару мегабайт, но тоже пространство бывшего СССР за пару лет в pbf выросло с 500 МБ уже до полутора гигабайт и я думаю порог в 2 ГБ мы преодолеем ещё к осени.

А что касается самого «нового» векторного формата, то это только ещё одна прослойка, отнюдь не тривиальная в установке и добавляющая головной боли и в идеале ну совсем никак не коррелирующая с бакэндом, хранящим пространственные примитивы.
dkiselev 2013
Можно подумать что мапник ставится, настривается и запускается проще чем постгисина. Данные импортятся долго, но тут скорее помоглобы еслиб кто выкладывал дампы по регионам из pg_snapshot’а например.

Виктор
На счет sqlite. Если вы в sqlite планируете хранить данные осм как есть, точки, веи ссылающиеся на линии и отношения ссылающиеся на что угодно, то любому приложению которое попытается по таким данным что то быстро рисовать поплохеет. Если же подразумевается что дамп sqlite содержит уже готовую геометрию, то генерация такого дампа это не быстро и не просто. Ну точнее или быстро или просто.
Виктор 2013
Я тестировал sqlite и postgresql. R-tree индексы в sqlite достаточно быстрые штуки просто его надо уметь настроить. Кто сомневается, что sqlite быстрая база данных всегда рад посмотреть на замеры :)

В общем-то здесь есть непонимание, если мы рассуждаем о сайтах с показом карты всего мира, то тут postgresql нормально, настраиваешь и работаешь.

Но если мы говорим о Mapnik для того, чтобы протестировать рендеринг локально, настроить что-то, показать друзьям, то тут он вполне может работать со встроенное и настраиваемой БД. В плане запустил Mapnik, указал папку с obf-файлами, а он уже встроенную БД или сервер подтянул.
Благо встроенных БД полно (не нравится sqlit, firebird возьмите).
Виктор 2013
* папку c pbf, o5m файлами
Maks Vasilev 2013
Для небольших объёмов можно читать напрямую из osm файла, такая функциональность была заявлена и это более предпочтительно, потому что рендер не должен делать «запустил Mapnik, указал папку с obf-файлами, а он уже встроенную БД или сервер подтянул». Это задача стороннего софта, всяких обвязок, гуёв и прочего.

К тому же ваша фраза «R-tree индексы в sqlite достаточно быстрые штуки просто его надо уметь настроить» сводит на нет само использование sqlite, т. к. нет разницы какую DB придётся настраивать, всё равно надо настраивать.

Повторюсь: не должен рендер работать конвертором pbf (osm, om5) в любой другой формат, а потом сам же поднимать экземпляр базы в этом формате и использовать его. Это не задача рендера, это задача стороннего софта. Напишите утилиту osm2sqlite по аналогии с osm2pgsql и используйте её в скриптах по своему усмотрению, а к мапнику нужно только дописать коннектор для ещё одной DB.
Zkir 2013
надо будет собраться, и все-таки написать рендерилку на основе котика для польских файлов с серверной частью на чистой джаве, без всяких дебильных баз данных и кретинистического питона)
bopoh13 2013
Я не пол: формат SVG мёртв? Тогда почему в этом формате иконки Mapnik-а лежат?
Maks Vasilev 2013
Zkir, да да! На батниках и визуалбейсике!
Maks Vasilev 2013
Формат SVG не мёртв, а неудобен для использования его в качестве формата тайлов, поскольку более избыточен по сравнению с растром небольшого размера. А вот в качестве формата вообще никто его не отменял.
bopoh13 2013
Maks Vasilev, спасибо за пояснение.

>> На батниках и визуалбейсике!
ЗЫ: Могу посодействовать XD
Zkir 2013
Посмотрел доклад Michal Migurski, доклад не плох, но два вопроса остались нераскрытыми.
1. Причем здесь остановка роста частоты процессоров?
2. Чем osm-xml, отдаваемый osm-api, не векторные тайлы?
dkiselev 2013
Zkir, тем что надо полигоны собирать из отношений, тем что эти полигоны не нарезаны на тайлы, и вообще не попадут в ответ если тайл не  охватывает хотябы одну точку границы полигона.
Zkir 2013
dkiselev, вот нет. Т. е. это явные косяки osm-api, но это не главное.
Zkir 2013
Причем эти косяки даже мешают простому редактированию в JOSM. Например скачиваешь квадрат, а проходящие через этот квадрат дороги не захватились, потому что они прямые и у них нет нет в этом квадрате точек.
dkiselev 2013
Zkir, и и и? Типа с этими недостатками осм апи формат выдачи осм апи становится пригодным для рендера?
Zkir 2013
Если эти недостатки исправить, осм-апи станет пригоден для рендеринга тайлов __восемнадцатого__ (самого подробного) зума.

Но что будет, если я попрошу z1? что я получу, 27 Гиг вектора?

Основное свойства тайла — иметь ограниченный размер, вне зависимости от масштаба.

В случае растровых тайлов это достигается автоматически. Даже если я исхитрюсь отрендерить береговую линию всего мира из 100500000 отрезков, все равно объем тайла не сможет превысить 196 кб (256*256*3)

Для векторных «тайлов» встает вопрос об отборе и _упрощении_ геометрии (генерализации). Отсюда и в докладе слайд про Natural Earth. Это самый напрашивающийся путь. z18-z11 — осм, z10-z1 — что то другое, не осм.
Популярное