8 ноября 2015-го

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Из викимедии с любовью

Вот викимедия. Вот отдел связности внутри викимедии. Вот направление карт внутри отдела связности внутри викимедии. А вот Kartotherian со странным названьем, что в направлении карт создали, что внутри отдела связности, что внутри викимедии. Это движок карт, соединяющий инфраструктуру векторных тайлов Mapbox, сервисы викимедии, и добавляющий несколько полезных инструментов. Он работает уже несколько месяцев на maps.wikimedia.org.

Главный разработчик Kartoterian предложил, заодно, перевести на него и osm.org. Админы, разумеется, повторились, что рано или поздно все там будем, но давайте попридержим коней. А следующим выступил Кристоф Хорманн с общей критикой векторных тайлов: конечно, они быстрые, и позволяют бесплатные вариации стилей (например, для «ретины»), но прежде всего, векторные тайлы ограничивают дизайнера стилей. Он сослался на статью в своём блоге и заметил, что все карты на векторных тайлах нынче выглядят одинаково, без изюминки.

В чем проблема, на самом деле? Идея же хороша: промежуточный шаг между данными и растром. Исторически все рендереры шли напрямую: из данных плюс стиль выдавали картинку. Векторные тайлы служат двум целям:

  1. Одни и те же данные для разных стилей. Примеры — векторные тайлы Mapbox Streets, или что использует Энди Аллан для своих карт Thunderforest, две из которых есть на osm.org.
  2. Разные форматы файлов для одной карты. Пример — Mapbox Vector Tiles, когда уже подготовленные и готовые к рендерингу данные сохраняются в отдельный файл, и затем на лету превращаются в растр. Не особо отличается от SVG, но и не слишком гибко. (Замечу, что я немного отстал от «паровоза», и настолько жёсткого формата, может, на самом деле нет).

Если разрезать на тайлы все данные, возникает куча проблем. Самая большая — потеря контекста. Нужны окружающие данные и наивысшая точность, т. е. в идеале — одна картинка на весь мир, сделанная из сырых данных. Для эффективности эту задачу упрощают: например, отрисовывают мир метатайлами, и делят данные на слои. Возникают граничные случаи, от чего, например, появились буферные зоны (по полтайла с каждой стороны метатайла). Так вот, в векторных тайлах после обработки остаются отдельные тайлы с буфером, и непонятно, например, куда ставить значки и подписи у больших или длинных объектов. Вместо того, чтобы решать самую сложную проблему картографии, векторные тайлы её усугубляют. Как с этим справиться, пока никто не знает, хотя Mapbox придумал пару обходных финтов, вроде предвычисления расположения подписей.

Карты на векторных тайлах, конечно, непохожи друг на друга: достаточно посмотреть на космические, карандашные, пиратские, деревянные, туристические карты на одних и тех же тайлах Mapbox. Но если этими картами пользоваться, то обнаруживаешь, что там везде одно и то же. Либо ты сводишь картографию на векторных тайлах к выбору цветов, значков и шрифтов, либо создаёшь свои полсотни слоёв, тратишь полгода, чтобы обойти ограничения формата, и в итоге получаешь примерно то же, что на CartoCSS, только с запутанной серверной инфраструктурой на JavaScript. Так что отчасти Кристоф прав: либо технологии, либо качество карты.

Поспорить с Юрием Астраханом, который с группой помощников разрабатывает Kartotherian, можно будет 21-22 ноября в Москве на конференции «Открытые ГИС».

josm-tested XVII

На прошлой неделе вышла новая «стабильная» версия редактора JOSM, 8969, и первое, что удивило обновившихся на неё, было окном «какому сегменту присвоить идентификатор исходной линии». По ходу, авторы не шутили, когда назвали экспертный режим экспертным: обычный человек ни разу не задумывался о сохранении id при разбиении линии. И уж точно не планировал делать выбор при каждом таком действии, как поначалу предположили разработчики. Именно так: на десять дней в ежедневной сборке latest операция разбиения линии превратилась из незаметной в тяжёлый и неожиданный выбор правильного сегмента каждый раз.

В остальном, полгода работы над редактором свелись, в основном, к полной переработке тайлового кэша, который теперь объединён с кэшем WMS. Ещё у подложек появилась настройка яркости (со странным значком на кнопке), а благодаря плагину «RasterFilters», написанному в рамках GSoC, можно подкрутить другие параметры изображения. Маркеры GPX, наконец, можно превратить в слой данных, и добавили панель с мини-картой: даже мини-карту разработчики посчитали важнее building_tools.

Для пользователя (-эксперта) главным улучшением стала загрузка данных из Overpass API, чем раньше занимался плагин mirrored_download. Окно, вызываемое из меню «Файл», позаимствовало алгоритм помощника из Overpass Turbo: достаточно ввести что-нибудь вроде «highway=primary and ref=*» и нажать «составить запрос», чтобы не лезть в учебник по Overpass QL. Жаль, что в отличие от веб-альтернативы, этот редактор запросов не даёт полного контроля: ограничивающий прямоугольник применяется в любом случае.

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

← Ctrl →
· · ·   10 ноября 2015