Amaroussi: «магистрали на основном стиле должны быть синие, высвобождая розовый для trunk. И хорошо бы сделать слой с альтернативными, „британскими“ цветами, и добавить его на osm.org».

Tom Hughes: «а почему только англичанам такая привилегия? Давайте ещё сделаем французский, американский, китайский стили».

Maarten Deen: «согласен, синий нужно вернуть. Он используется на знаках магистралей и в других европейских странах».

Simon Poole: «а в куче других европейских стран знаки зелёные. Непонятно, зачем нам быть заложниками странного решения третьей стороны (ссылается на Ordnance Survey)».

Frederik Ramm: «странно, что вы настаиваете на заимствовании цветов знаков. В Германии, например, знаки магистралей тоже синие, но их цвет — первое, что поменяли, когда в 2011 году делали немецкий стиль: мол, синий никто, кроме британцев, не любит».

Richard Fairhurst: «в восемьсотшестисотый раз: старый стиль использовал синий, зелёный и красный не из-за Ordnance Survey. Эти цвета стандартны для английских карт, и другие картографы рисовали зелёные дороги класса А задолго до OS, которые поменяли цвет лишь в девяностых.

Из коммерческих карт, работы AA Maps будут ближе к нашему старому стилю, хотя на самом деле, цвета мы взяли из моей карты каналов 2004 года, только насыщенность поправили. Да и шильдики дорог не позаимствовали у OS, как некоторые трезвонили. Они похожи разве что на знаки сетей British Railways пятидесятых».

Пол Джонсон в рассылках tagging@ и talk@ обратил внимание на тег ref=* на дорогах. Ещё со времён API 0.5, в котором не было отношений, им объединяли дороги в сети маршрутов. При этом нет простого способа проверить связность такой сети; несколько маршрутов на отрезке требуют точек с запятой, которые сложно обрабатываются; и легко смешать номера маршрутов и номера дорог, где они различаются. Зачем, когда у нас уже восемь лет как есть отношения, в частности — route=road. Пол предлагает за год повсеместно внедрить это отношение, и на картах отображать номера из отношений, а не из тега ref.

Одним из первых возражений была невозможность в osm2pgsql взять атрибуты для линии из содержащего её отношения, на что выдали контрпример с американскими магистралями. Ричард Велти замечает, что для длинных маршрутов они создают супер-отношения, которые использовать сложнее — но иначе маршрут не загрузить в редактор. И конфликтов не оберёшься. А Komяpa в твитере таинственно намекнул, что выходить за пределы рамок OGC Simple Features чревато.

Затем упомянули сложность редактирования и слежения: одно дело, когда через дорогу проходят десять маршрутов, другое — всего одно число в ref, ради которого раскочегаривать редактор напряжно, да и следить, чтобы отношение не поломали, лениво (а когда ломают последовательность ref, это, видимо, не так мозолит глаз). Пол гневно возразил, что это проблема редакторов, а не людей, и Ричард, автор Potlatch, тут же попросил его умерить пыл. И привёл пример местных веломаршрутов: с ними всё в порядке, вот только новички постоянно создают копии и копии копий, потому что не видят, что отношения маршрутов уже есть.

В целом, задача не выглядит сложной, главное — людей переубедить. В talk@ дискуссия получилась куда короче: «а, ну ок». Но ключевыми людьми в сценарии перехода означены авторы картостиля, а у них и так тикетов невпроворот. Да ещё и перезаливка базы требуется. Правда, её хотят перезалить так и так, потому что для стиля критически не хватает новых тегов, и нужен hstore с их полным комплектом.

Вот викимедия. Вот отдел связности внутри викимедии. Вот направление карт внутри отдела связности внутри викимедии. А вот 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, 8969, и первое, что удивило обновившихся на неё, было окном «какому сегменту присвоить идентификатор исходной линии». По ходу, авторы не шутили, когда назвали экспертный режим экспертным: обычный человек ни разу не задумывался о сохранении id при разбиении линии. И уж точно не планировал делать выбор при каждом таком действии, как поначалу предположили разработчики. Именно так: на десять дней в ежедневной сборке latest операция разбиения линии превратилась из незаметной в тяжёлый и неожиданный выбор правильного сегмента каждый раз.

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

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

У компании Scout много автомобильных треков: их навигатор, кажется, отправляет их на сервер по умолчанию, если не отключить. Для нас это хорошо, потому что хотя компания и не выдаёт весь архив, её сотрудники анализируют весь массив треков и сравнивают его с данными OpenStreetMap. И время от времени мы получаем новые валидаторы.

Первый проект Мартайн показал месяц назад: это результат сравнения треков с дорогами, слой Missing Roads. Его можно посмотреть в браузере, или добавить в JOSM, установив плагин «missingRoads». На низких масштабах там «тепловая карта» всех ошибок, а с 15-го подгружаются квадраты с точками треков. Дальше всё очевидно: если под треком нет дороги, её нужно дорисовать.

На прошлой неделе мы получили второй проект, который тоже про сравнение треков с дорогами, но чуть сложнее: слой Traffic Flow Direction находит потенциально односторонние дороги, где в OSM обозначены двусторонние. Его также можно посмотреть и подключить в JOSM (плагин «trafficFlowDirection»). Неожиданным было отсутствие oneway прямо в центре Москвы, хотя в европейских столицах и американских городах таких ошибок больше — за счёт распространённости навигатора Scout.

Распространённость Scout — главный недочёт этого валидатора: восточнее Германии у них треков очень мало, и проблем сервис почти не видит. Недочёт вытекает из закрытости исходников: мы не можем, например, обработать базу треков OpenStreetMap. Мартайн пишет, что готов сделать это сам, но сначала нужно выдавить из Гранта, нашего админа, обновление дампа GPX: последний делали больше двух лет назад.