Позднее Ctrl + ↑

josm-tested XIII

На этой неделе вышла «стабильная» версия JOSM, 7182. О главной новой функции уже оповестил akks на форуме: в нагрузку к функции «включить точку в линию» появилась её альтернатива, которая работает именно так, как ожидаешь: «переместить точку на линию». Отличается тем, что двигает точку, тем самым не искажая прямые. По умолчанию ей не назначена клавиша, и я не нашёл способа это сделать, но очевидно, именно эту функцию теперь должна запускать кнопка «J».

Другое эпическое новшество — для выделения многоугольника достаточно дважды кликнуть внутри него. Кроме того, при выделении двух точек в строке статуса выводится расстояние между ними (можно выделить и линию, да). И если вас бесит в режиме вытягивания, что нельзя вытянуть на чуть-чуть, теперь можно уменьшить значение параметра extrude.initial-move-threshold.

В новой версии завершены два долгих процесса: во-первых, она теперь требует Java 7. Если вы не можете обновить шестую, оставайтесь на предыдущем tested, версии 7000. Во-вторых, MapCSS заметно ускорился и поглотил вообще всё: в январе на него перевели всю систему валидации, а теперь — основной стиль отображения. Больше никакого XML, никакого хардкора.

Из старых новостей — в феврале в ядро перенесли плагин wayselector, который выбирает цепочку отрезков с похожими тегами: например, береговые линии или дороги. Он не заменяет функцию «Выделить дорогу» плагина utilsplugin2, которая при выборе объектов учитывает теги name/ref и умеет искать маршрут между двумя выделенными отрезками. И тогда же разработчики смирились с тем, что автоскрытие кнопок нравится только им, и отключили его по умолчанию.

Don-vip, один из разработчиков, уже полгода перечисляет в своём дневнике основные изменения каждой версии.

Инструментарий картопечатника

Как только я начал готовить печатный вариант карты маршрута на основе своего стиля, я обнаружил, что инструментов-то и нет. Вернее, есть, но не те. Например, подвинуть надпись в векторном изображении, выданном мапником, нетривиально: нужно выделить все буквы надписи, затем все элементы её полупрозрачного фона. Это нелёгкий процесс, с тщательным прицеливанием и нецензурными репликами, когда выделение теряется. Не двигать нельзя: алгоритм расстановки надписей в мапнике ужасен. Движок Cairo, используемый мапником, не позволяет объединять элементы слоёв в группы. Поэтому месяц назад я опубликовал скрипт mapnik-group-text, который объединяет буквы во фразы. Из параметров важен только -d, который определяет максимальное расстояние между буквами.

Затем мне понадобилось сделать выгрузки огромных территорий для OziExplorer (велосипедисты, почему-то, любят этот дорогой артефакт истории). Из существующих скриптов — только nik2img, который щеголяет несколькими десятками опций (но треть из них к делу не относится). Попробовал для проверки получить картинку как на osm.org, задав центр, масштаб и размер картинки в пикселях. Скрипт разочаровал: масштаб съехал на полделения. Как получить картинку в 300 dpi, вообще непонятно: при указании scale_factor лишь все линии зачем-то становятся толще. Что делать — пришлось писать самому.

Nik4 отрендерит вам мапником картинку именно так, как нужно. Без сюрпризов. Хотите эквивалент скриншота osm.org в нужной точке? Запускайте с параметрами -c LON LAT -x 800 600 -z 13. Распечатать прямоугольник в 300 dpi на листе A5? -a 5 --ppi 300 --bbox X1 Y1 X2 Y2 — и не нужно знать, что такое scale_factor, или какое там разрешение по умолчанию. Подготовить огромный фрагмент для Ozi? --tiles 4 склеит большую картинку из 16 маленьких (чтобы не вылететь по нехватке памяти), а --ozi output.map создаст файл привязки. Подробные примеры с картинками смотрите на гитхабе, а для установки достаточно набрать pip install nik4.

Первой задачей, с которой сталкиваются установившие мапник, остаётся генерация тайлов. Для этого я много лет назад написал скрипт polytiles.py, который не только делает эти тайлы в несколько потоков, но умеет собирать их в mbtiles и фильтровать как по файлу poly, так и по произвольному полигону в базе PostGIS (например, по городу). Недавно открылось ещё одно применение скрипта: им элементарно делать списки для renderd, чтобы обновлять тайлы в заданном регионе.

Работа над ошибками

После заметки, полной горечи, об указании авторства, два самых известных русских пользователя наших данных добавили слово OpenStreetMap на страницы с картами. Большое спасибо программистам и юристам проектов «Спутник» и «2ГИС»! Надеемся, их сотрудничество послужит примером для остальных.

«Veloroad»

Две недели назад у нас появился новый картостиль. Как вы знаете, использовать наши тайлы для чего-то, кроме рассматривания на экране, неприятно. Велосипедные сообщества Петербурга медленно переходят на OSM, но подобное качество подложек делает карты бессмысленными для ориентирования (и жуткими на бумаге). Я давно планировал сделать низкодетальный стиль для веломарафонов, и, наконец, технологии позволили: как TileMill с почти мгновенной обратной связью, так и облака, сделавшие серверы с большими дисками доступными. Встречайте и сравнивайте: Veloroad, первый человеческий стиль для печати маршрутов.

Про разные технические мелочи я уже рассказал на форуме, а здесь — слайды: чем стиль отличается от остальных. На сайте есть кнопка, открывающее второе окно для сравнения.

На восьмом масштабе стандартный слой показывает только place=city, слои кирово-чепецка и яндекса — place=town, а на veloroad появляются place=village (hamlet — на десятом). Большие расстояния между метками и правильная сортировка не дают карте утонуть в надписях. Это и другие решения вытекают из того, что стиль предназначен для печати, и на бумаге нельзя изменить масштаб, чтобы присмотреться к какой-то части карты. Отсюда же и мелкие буквы: при печати в 300 dpi восьмой размер читается проще, чем на экране в 90 dpi.

Для отображения зарубежных названий используется name:ru. Тут могут быть несколько мнений: для навигации вернее, конечно, использовать названия в том виде, что будут на табличках, но некоторые участники велосипедного форума жаловались, что в Грузии получается вообще нечитаемо. Ну и устно проще прочитать «встречаемся в Козе-Ууэмыйзе», чем неправильно транслитерировать, и оттого разминуться.

Подписи дорог рисуются сбоку, поэтому когда дорогу закрывает линия трека, подписи остаются. Какой смысл рисовать карты, где не подписаны именно те улицы, по которым проходит маршрут, мне непонятно. Также, благодаря идее Котяры, воплощённой в его komap, на veloroad улицы подписаны с 12 масштаба, и эти подписи видны и читаются. Даже у Яндекса нормальные названия улиц появляются только на z14, из альтернатив подписи сопоставимы только у стилей на MapCSS: то есть, на чепецк.net. Статусные части, разумеется, сокращены.

Светло-зелёный, чтобы не засорять карту, лес появляется только на 11 масштабе (на мелких в нём нет смысла для ориентирования, да и красоты немного), а грунтовки и highway=unclassified — только с 12: в отличие от чепецкого, стиль veloroad предназначен для маршрутов длинных путешествий, преимущественно по дорогам от tertiary (рисуются с z9) и выше, и для городских покатушек. На osm.org все дороги внезапно появляются на 10 масштабе, но пользоваться этой мешаниной невозможно.

Железные дороги рисуются только основные (без service=*). К сожалению, многие станции всё равно напоминают вермишель, но, по крайней мере, не теряются важные линии, как на MapSurfer, где на мелких масштабах рисуются только пути с usage=main. Особенно я горжусь станциями, которые поворачиваются вдоль путей: ни на одном другом веб-стиле они не выглядят так хорошо.

При этом станции метро не отображаются вообще. Вместо них рисуются railway=subway_entrance, причём с 12 масштаба. Это единственный, блин, стиль OSM, который не вызывает у новичков вопроса «почему станции метро находятся совсем не там, где должны». Все остальные стилеписатели сомневаются и тянут сопли, извините. Отображать на гражданской карте расположение подземных станций метро — глупость и леность.

Другой предмет споров с новичками — полигоны place=*. Из-за того, что их нет на большинстве стилей, некоторые вешают на них лишний тег landuse=residential. На масштабах 9-11 стиля veloroad территории населённых пунктов определяются по полигону place, на более крупных — складываются из основных landuse.

Горизонтали отображены на масштабах, где в них есть смысл. Пока что только западнее 60° восточной долготы (т. е. Урала). В отличие от большинства остальных карт, рельеф сглажен (использован GMTED2010), поэтому на равнинных территориях горизонтали не превращаются в шедевр импрессионизма, а корректно идентифицируют стометровые холмы. Бергштрихи показывают направление уклона: без них изолинии не имеют смысла.

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

К сожалению, за разумные деньги можно купить лишь небольшой сервер, поэтому рендерится (с ежеминутным обновлением) лишь северная часть страны: полностью Северо-Западный, Центральный и Дальневосточный федеральные округа, части Уральского и Сибирского, а также полностью страны Прибалтики и восточный кусок Финляндии. Многие северные территории нашей страны лишь на стиле veloroad можно окинуть взглядом: даже Яндекс там рисует только реки, как будто они важнее прочего. Безответственное отношение к картостилям — одна из причин, почему OpenStreetMap не воспринимается всерьёз, и я надеюсь, стиль veloroad поможет показать качество и полноту проекта.

Другой CSS

Хотя после создания своего картостиля я наглухо засел в лагере Carto, не могу не радоваться экспансии MapCSS. В последнем josm-tested на него полностью перевели стандартный стиль, отказавшись от старого XML. Komap давно не развивается, но есть альтернатива: Stephan Bösch-Plepelits поддерживает версию стиля osm.org в MapCSS, и с августа постоянно выпускает новые версии PGMapCSS — интересного подхода к подготовке мапниковского стиля.

Судя по описанию, превращать MapCSS в XML (как делал komap) недостаточно: PGMapCSS также запихивает всю обработку данных в функции базы данных PL/Python3, которые вызывает сгенерированный стиль. Он поддерживает вычисляемые параметры, которые появятся в Mapnik 3, пока что через обработку всех возможных значений. Также в него проникли некоторые приятные штуки из komap: например, объединение дорог по названиям, чтобы карта не пустовала. Сочетание eval() с некоторыми специфичными для PGMapCSS селекторами позволяет творить чудеса: можно отрисовывать только часть линии, можно строить подписи из каких угодно данных, можно связывать близко расположенные объекты (например, выводить название улицы для кафе на ней). И всё это не требует знания SQL, в отличие от CartoCSS (хотя названия функций в eval() подозрительно напоминают функции PostGIS): просто пользуйтесь практически тем же языком описания картостилей, что и в JOSM.

В разделе примеров некоторые поражают воображение. Все их можно посмотреть по ссылкам на подсайт OpenStreetBrowser, развивающий идею котяриного онлайн-редактора, пусть не в браузерном варианте, и не такой красивый, как TileMill. Неделю назад вышла очередная версия PGMapCSS, с которой можно смешивать MapCSS и обычные XML, пользоваться eval() в селекторах и значками из набора Maki.

Ранее Ctrl + ↓

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