opentopomap.cz – топографические карты opentopomap для наших условий

Как выделяют на советских\российских топокартах — цветом, с ПТФ однозначно не спутать.

Я понял. На генштабе по цвету отличаются кварталы с разной плотностью застройки и разной степенью огнестойкости. Плюс некоторые вариации в зависимости от масштаба. ПТФ там, или нет, без разницы. Посмотрите легенду. Не актуально, так как я надеюсь, что эта карта не будет применяться для расчёта зоны поражения после ядерного удара и средней скорости прохождения живой силы и техники через кварталы.

Спасибо за разработку!
По поводу кварталов хотел бы попросить если есть такая возможность чтобы различалась цветом многоквартирная (городская) застройка residental=urban и индивидуальная (сельская) residental=rural - можно как в “Генштабе” или стиле Topo в OSMAnd. Также если можно сделать отображение разрушенных зданий building=collapsed - можно пунктиром.

Еще одно моё пожелание может быть спорным и Вы его не поддержите, но лично бы мне хотелось более насыщенных цветов карты - по аналогии с Генштабом и ГГЦ - особенно для водных объектов, лесов, садов, застройки.

ВАХЪ !! Большое пожелание процветать проекту. альтернатив в РФ подобной карте нет.
с хотелками тормозну ибо смотрю и так завалили…

я, если честно, понятия не имею. Другие терминалы данного аэропорта отрисовываются

Огромнейшая просьба, кто умеет, так как я в этом не особо - скиньте параметры для SASPlanet, для opentopomap.org они такие:

DefURLBase=http://a.tile.opentopomap.org
ContentType=image/png
Ext=.png
projection=1
sradiusa=6378137
sradiusb=6356752
UseGenPrevious=1
Usedel=1
Usesave=1
UseAntiBan=0
BanIfLen=0

Нет не поняли, на топокарте цветом ПТФ (Птице-Товарная Ферма) ни как не выделяются, как и промзоны, в отличие от жилых кварталов и кварталов садоводств. Отличать жилую застройку от любой другой — это актуально, т.к сейчас они неотличимы.

Сейчас будет как в басне Слон-живописец.
— Вот landuse=industrial не вижу подписи с названием.
— Не вижу всякие скважины.
— С точки зрения городских житетей городские микрорайоны place=neighbourhood должны быть подписаны.

Paravoz, как то так, проверь. у меня вообще саспланета просто не работает, так не проверял :frowning:

если karnavalny не будет против могу пропихнуть в основной репозиторий саспланеты.

------------------opentopomap.ru.zmp\GetUrlScript.txt--------------
begin
GetURLBase[14]:=chr(ord(‘a’)+random(3));
ResultURL:=GetURLBase+inttostr(GetZ-1)+‘/’+inttostr(GetX)+‘/’+inttostr(GetY)+‘.png’;
end.

----------------opentopomap.ru.zmp------------------
[PARAMS]
GUID={64322788-9933-4268-3162-DAABBCCEE17E}
name=OpenTopoMap.RU
NameInCache=osm_topo_ru
DefURLBase=https://tile-b.opentopomap.ru/
ContentType=image/png
Ext=.png
projection=1
sradiusa=6378137
sradiusb=6356752
UseGenPrevious=1
Usedel=1
Usesave=1
UseAntiBan=0
BanIfLen=0
PARENTSUBMENU=OSM
IteratorSubRectSize=8,8
License=© OpenStreetMap contributors, CC-BY-SA; rendering opentopomap.ru

Спасибо огромное!

Не против.

Тут есть неточность. Тайлы генерируются в проекции EPSG:3857 (Web Mercator), соответственно, радиус большей и меньшей полуоси эллипсоида должны совпадать, т.е.


sradiusa=6378137
sradiusb=6378137

Изначально я хотел сделать карту в “честном” Меркаторе EPSG:3395, но оказалось, что проблема совместимости таких тайлов с разным софтом будет довольно острой. Сейчас всё приспособлено под 3857. Редко кто знает, что земля не является шаром. Две базы, по крайней мере тайлов, для одновременной работы с двумя проекциями мне показалось иметь расточительным, да и мои задачи “честного” Меркатора особенно не требовали. А обычный пользователь скорее всего вообще не очень поймёт, о чём речь.

А потом юзеры САСа положат Карнавальному сервак))

Возможно стоит сортировать дороги по важности при отрисовке заливки, чтобы толстый транк не был изрезан белыми улицами.

потребитель не знает таких вумных слов как прооекция и т.д. :slight_smile:
в обывательском тырнете есть две проекции:
правильная - гугловская (3857)
неправильная - яндексовская (3395) :slight_smile:
все остальное - магия и потусторонние звуки… :slight_smile:
ок, подправлю и отправлю в репозиторий.

Отличная карта!

Но лично мне хотелось бы видеть мелкие дороги и тропы на более мелких масштабах. Существует ли возможность менять “глубину детализации” в зависимости от плотности объектов в данном месте карты?

Например, между Старой Рачейкой и Троицким много грунтовых дорог и троп, которых в режиме “всё сразу” не видно, надо приближать: https://opentopomap.ru/#map=12/53.3758/48.2097

Я, когда пытался делать свою карту, рисовал hw=track аж до 10-го масштаба: http://cycletrailmap.romanshuvalov.com/r/12/53.3947/48.2234

При этом в густонаселенных и высокодетализированных местах, возможно, будет каша.

Если такой возможности нет, то предложение: на масштабах от 14-го до ~10-го рисовать hw=track и hw=path, но с уменьшением масштаба плавно менять цвет на более бледный и делать линии более тонкими.

И ещё, у вас карта высот с viewfinderpanoramas, а там не только SRTM, но и ASTER GDEM используется. Возможно, стоит это указать в копирайте.

что, похоже, уже положили сервер?

Там ещё и

Ссылка на них стоит, а уж что они точно применяли, пусть останется на их совести.

Вроде всё бодренько журчит. Или вы наблюдаете какие-то проблемы?

не грузился сайт, но теперь уже все ОК

Теоретически можно написать анализатор плотности объектов на данной площади, но сейчас никакого механизма для этого нет. Я не уверен, что динамически менять глубину детализации очень хорошая идея, так как более правильно ожидать определённой детализации на определённом зуме. Чтобы пользователь знал, что если, скажем, на 15-м зуме нет названия у СНТ, или какой-нибудь дороги, то их физически нет в базе, а не какой-то алгоритм решил, что в этом месте их не надо показывать.
Похожий алгоритм, как сторонний и довольно негативный эффект, есть при отрисовке отдельных точечных объектов, типа родников, лавок, укрытий и т.п. Когда два разнородных объекта находятся очень близко друг от друга, и на данном масштабе перекрываются. Приходится выбирать, что рисовать, а что нет, иначе на карте появится мусор. Только кому-то важно одно, а кому-то другое. Это очень неприятная вещь, с которой ничего не поделаешь, кроме как увеличением максимального зума или генерацией карты в векторе. Одной из причин появления 18-го зума было желание уменьшить количество таких коллизий.

Тут проблема в том, что кроме возможного замусоривания карты, может очень существенно увеличиться нагрузка на рендер, причём совершенно нелинейно. К примеру, дороги и некоторые другие объекты до 10 масштаба включительно строятся по специальным, заранее генерализованным данным, а не напрямую из основной базы. Иначе никаких разумных ресурсов не хватит для отрисовки мелких и средних масштабов. Кстати, самые затратные зумы - средние. Там много объектов, а информация слабо генерализована. Добавлять туда ещё что-то без крайней необходимости, может оказаться не очень хорошим делом. Например, мне пришлось отказаться от сшивания полигонов на зумах меньше 14-го, так как даже на 13-м зуме в некоторых областях выборка из базы и последующий рендеринг стандартного блока тайлов мог занимать пару минут, что, понятно, никуда не годится. На текущий момент есть баланс отсутствие_“каши”/скорость/полнота_информации, и, не скрою, оптимизация для пешего туризма. Тем не менее, я подумаю над вашим предложением, посмотрю, как это будет выглядеть на карте, а также по скорости и уже тогда приму решение. Для “базового лагеря” рекомендую монитор побольше, на 32-х дюймовом мониторе 2560x1440 всё выглядит просто великолепно.