Для топопланов нужен совершенно другой рендер, там нет ничего общего с топокартами и их символикой. Но я понял мысль - символики 1:25000 не хватает на более крупных масштабах, карта становится пустой, излишне генерализированной.
Да, совершенно верно. При этом OSM в основных населенных пунктах уже содержит достаточно информации, чтобы сделать крупные масштабы (17-19) информационно насыщенными. Но пока я не знаю ни одного рендера, который бы это использовал. Хотя opentopomap.ru наверное наиболее подробный рендер в вебе на крупных масштабах из всех что я видел, думаю это в значительной мере и объясняет его популярность.
Кстати, такие топопланы могли бы стать главной конкурентной фишкой OSM. Тем более, что в плане POI и маршрутизации (пробки) OSM уже вчистую проиграл коммерческим картам. Но это тема уже не для этого топика, сорри 
Добавлен рендеринг wood:age=young и very_young, то есть поросль леса. Стиль подобен генштабовскому. Также, пересыхающие родники и колодцы (intermittent=yes) c 16-го зума теперь подписываются соответствующе. Ещё я добавил отрисовку ворот c проставленными запрещающими правами доступа access, foot или motor_vehicle , находящихся на railway=*.
opentopomap=# select count(*) from planet_osm_point where barrier='gate' AND (foot IN ('no', 'private', 'forestry', 'agricultural') OR motor_vehicle IN ('no', 'private', 'forestry', 'agricultural') or access IN ('no', 'private', 'forestry', 'agricultural')) and direction is null;
count
-------
11042
(1 строка)
opentopomap=# select count(*) from planet_osm_point where barrier='gate' AND (foot IN ('no', 'private', 'forestry', 'agricultural') OR motor_vehicle IN ('no', 'private', 'forestry', 'agricultural') or access IN ('no', 'private', 'forestry', 'agricultural'));
count
-------
73266
(1 строка)
То есть не отрисовывается 11042 из 73266 ворот с проставленными правами доступа, или 15%. Если хотите, могу выложить файл с osm_id этих объектов.
В принципе, сейчас меня всё более-менее устраивает.
Светлее и тоньше уже некуда, толщина 1 пиксел с прозрачностью 0.5-0.9 в зависимости от масштаба. Просеки должны быть контрастными, для распечатки на бумаге. Это важный ориентир в лесу. Кроме того, их стиль соответствует легенде карт Генштаба.
Потому что на нём нет тегов access, foot или motor_vehicle, запрещающих доступ.
А какие проблемы его использовать на мобильных устройствах?
Если вам не трудно, добавьте пожалуйста на стороне веб-сервера заголовок Access-Control-Allow-Origin: *
Браузеры стали довольно капризны и для краткосрочного сохранения тайлов через leaflet и оффлайн плагины требуется такое разрешение. Это немного снизит нагрузку на ваш сервис за счёт меньшего количества обращений. И ещё раз спасибо за такой прекрасный рендер!
UPD: суть проблемы: https://github.com/MazeMap/Leaflet.TileLayer.PouchDBCached#cross-origin-resource-sharing
Добавил.
Есть ли возможность выделить отдельно покрытие дорог?
Например вот здесь: https://opentopomap.ru/#map=18/53.90307/27.29177 вся дорога выделена желтым из чего можно сделать вывод, что это асфальтовая дорога. Однако это не так. Левая часть это гравейка. Это хорошо видно например на карте OpenHikingMap на ресурсе https://gpxstudio.github.io/. И это действительно так, живу я рядом.
Хоть пока и не спрашивали “зачем”, отвечу: на велике зимой катать.
По асфальту жутко неинтересно и опасно.
По лесным дорогам невозможно.
Зато по гравейкам самое то.
И я испытываю определенные трудности в поиске новых гравеек, где я еще не катался, коих становится все меньше и меньше.
В качестве фильтра для поиска гравеек думаю можно использовать вот такую строку:
“surface=compacted|gravel|raw|winter|unpaved”.
Я думал об этом, но пока не понял, как это можно красиво и функционально сделать.
Правило с жёлтой заливкой работает только для дорог типа unclassified.
Для вашей задачи очень подходит https://overpass-turbo.eu/.
Почему не скопировать уже сделанное на OpenHikingMap?
Если такая карта будет, то ее можно будет использовать в навигаторе.
За ссылку спасибо. Это то что нужно.
Для ПК это отличное решение.
И теперь стало понятно, что увидев нужное покрытие я свою задачу не решу. Потому как очень много неточностей. Много где нарисован асфальт, которого нету и никогда не было. Или лесные дороги, показываются как дороги с покрытием.
Если вы имеете ввиду http://maps.refuges.info/ (единственное работающее, что я нашёл по ключевому слову OpenHikingMap), то в её легенде нет поддержки тега surface для дорог (https://wiki.openstreetmap.org/wiki/Hiking/mri#Map_Legend), поэтому я не понял, что у неё можно скопировать.
Судя по вот этой статье: “https://wiki.openstreetmap.org/wiki/Hiking/mri” OpenHikingMap это есть старое название проекта OpenTopoMap.
В OpenHikingMap дороги же раскрашиваются в зависимости от покрытия, значит такая информация каким то образом хранится.
Для оверпаса написал запрос:
[out:json][timeout:25];
// gather results
(
// query part for: ““дорога НЕ асфальт””
way[“highway”=“tertiary”]“surface”=“gravel”;
way[“highway”=“tertiary”]“surface”=“compacted”;
way[“highway”=“tertiary”]“surface”=“unpaved”;
way[“highway”=“tertiary”]!“surface”;
);
// print results
out body;
;
out skel qt;
Вполне рабочее обходное решение для моей хотелки.
И можно все выгрузить в виде треков и потом смотреть на телефоне в навигаторе.
Вдруг кому то еще пригодится.
Это не соответствует действительности.
Почему бы не сделать как на советских топокартах: символ “А” в подписи — асфальт, “Щ” — щебень, “Г” — гравий? И заодно индексы дорог “щитом” оформить.
Потому что, например, в населённых пунктах это будет излишняя, и даже мусорная информация. Там актуальнее названия улиц. Но дороги населённых пунктов и за их пределами при рендеринге не отличить, поскольку эта информация в базе не хранится. Нужен очень ресурсоёмкий препроцессинг, который точно лишит возможности обновлять базу раз в день.
По этой же причине нельзя, например, все асфальтовые дороги залить жёлтым, а грунтовые и гравийные - белым. Тут же пожелтеют все города. Худо-бедно, да и то не всегда, это получается с unclassified, поскольку их сравнительно нечасто используют в российских городах.
Я считаю это недостатком базы openstreetmap. В своё время надо было предусмотреть тег, обозначающий, относится ли дорога к населённому пункту, или же нет. Хотя бы для таких случаев.
Относится ли дорога к населенному пункту несложно определить по вхождению в полигон place=*. Ограничения скорости в навигаторах работают именно по этому принципу и в подавляющем большинстве случаев работают достаточно хорошо.
Одни только операции по объединению смежных полигонов леса и воды, чтобы были красивые границы, по статистике занимают около 40% по загрузке процессора от всех выборок, несмотря на то, что работают только начиная с 14-го зума. Если ещё пытаться тут же определять входжения, то сервером можно будет отлично отапливать помещение, но не рендерить в реальном времени. Кроме того, тут нужно не просто определять признак пересекает/нет, но и вычислять участки пересечения и рисовать их отдельно, поскольку никто не обязует маппера резать дороги по границам населённых пунктов.
Навигатору не надо рендерить большие площади, плюс информация может быть подготовлена заранее при создании графа дорожной сети и т.п.
в навигаторах? а в каких? В Османде и мопсе, например, это не работает.
У вас что-ли в реальном времени все это рендерится? Вообще без препроцессинга и генерализации? O_o
Объединения полигонов - да. Поскольку они делаются только на квадрате выборки. Объединить смежные полигоны по всей базе заранее - это утопия, как по ресурсам (по explain’у там какие-то фантастические величины), так и по эффективности дальнейшего использования, поскольку тогда при выборке даже маленького участка может выбираться огромный объединённый и совсем не нужный полигон.
Надо полагать, что 90% дорог вне НП и отрабатываться должна в момент. А уж дорог выходящих из НП и которые надо порезать, можно посчитать по пальца.