Благодарю вас!
Похоже, ваша карта теперь единственная из современных, которая это отображает.
Возможно ли сделать такое: http://garmin.opentopomap.org/ с разбивкой файлов по областям и автоматической пересборкой раз в месяц, например? Это бы очень облегчило жизнь многим людям.
Замкнутые линии с тегом natural: earth_bank если замкнуты, то всегда отображаются как возвышение а не низина/яма, без учета фактического направления линии, что, похоже, ошибка.
Если разомкнуть, то направление учитывается корректно.
Технически это совершенно разные проекты. Всунуть эту карту в Garmin можно только в качестве растра, то есть с конвертацией тайлов через, например, SAS.Planet, в форматы jnx или img. Вдобавок, это должна быть более-менее современная модель с поддержкой растра, взломанной прошивкой или действующей подпиской BirdsEye. Последние два пункта обусловлены своеобразной политикой Garmin. Но всё равно так красиво, как на экране компьютера, не будет, из-за технических ограничений навигатора. Лучший путь - попросить тех, кто занимается конвертацией в векторный формат garmin, добавить нужную вам информацию в их проекты, и впоследствии использовать их карту. Сделать это можно в соседних темах.
И потом, хотя по-умолчанию объекты natural считаются полигональными (лес, вода та же), через скрипт lua можно рулить - полигон это будет или линия в итоге. Но и у полигона направление не куда не девается. Это уже косяк в стиле рендера.
Можно сделать упрощённое подобие этой карты. В точности нарисовать то же самое не хватит аппаратных ресурсов навигатора и его изобразительных средств. Но точечных объектов можно отобразить больше.
А разве это не часть проекта OSM?
На эту тему я уже писал. Но специально для вас, по всей базе полигонов:
opentopomap=# select count(*) from planet_osm_polygon where ST_IsPolygonCCW(way) IS TRUE;
count
----------
46039705
(1 строка)
opentopomap=# select count(*) from planet_osm_polygon where ST_IsPolygonCCW(way) IS FALSE;
count
-------
1
(1 строка)
То есть в базе все полигоны, кроме одного, закручены против часовой стрелки. Я посмотрел исходники osm2pgsql по диагонали, ничего специально портящего направления обхода вершин я не обнаружил. Но это надо разбираться глубже в форматах и т.п., возможно, в таком виде всё прилетает уже с geofabrik. И почему всё-таки один полигон закручен по часовой, мне тоже неизвестно. Но, повторюсь, при соблюдении правил в wiki, для рендеринга это совершенно без разницы.
да так и сколь помню было сделано. но гармин етрекс легенд потерян давно и теперь не скажу
нет. если быть точным, проект осм заканчивается на выгрузке planet.osm.xml на сайте http://planet.openstreetmap.org
только сбор, хранение и выгрузка геоданных.
всё остальное - вселенная сторонних проектов связанных (и не очень) с опенстритмап, безграничная и динамичная.
даже тайлы с опенстримап.орг, которые все и принимают за осм, не являются частью проекта
Емнип это osm2pgsql нормализует полигоны, чтобы outer и inner были в противоположных направлениях. Сейчас точно не помню, какое направление является стандартом по-умолчанию CW или CCW.
В этом плане imp2osm намного гибче (и быстрее), но он полностью поменяет структуру базы и потребует переписать все SQL-запросы в рендере.
А в одну сторону они потому, что база оперирует кольцами и для них имеет значение направление. Потому что внешнее кольцо должно быть направлено в одну сторону, а внутренняя дырка в другую.
Я воздержусь от подобного скрипта. Это может принести гораздо больше проблем, чем пользы. Мне кажется, что пользователь должен уметь пользоваться area=no или резать линии, в зависимости от контекста, тем более это есть в документации.
area=no избыточен, ибо семантика тега уже наделяет его свойством линейности. И корректная обработка данных возложена на потребителя. Это что называется - мапить под рендер.
Ок, на вскидку, не сильно погружаясь в тему скриптов и прочее. Есть inner в полигоне, нарисованный замкнутой линией, который пользователь отметил ещё и как, скажем, cliff. Так что это, линия, или вложенный полигон? Как тут отличать?
Не совсем понял вопроса. Но дополню по предыдущему. Это в ОСМ одна геометрия для двух объектов - для одного это дырка, для другого это основной контур. А в базе это уже два совершенно разных объекта - один объект с дыркой, а второй лежит поверх дырки. И в данном случае он вполне может быть не полигоном на дырке, а только её контуром, от этого первый объект никак не затрагивается.
Но изначально эта линия-дырка ведь имеет один osm_id? Соответственно, в pbf это один объект? И в два объекта она превратится только тогда, когда этот pbf обработается osm2pgsql? А вы уверены, что если скрипт сообщит, что это линия, а не полигон, osm2pgsql сможет корректно вырезать дыру в полигоне, который outer? Кто-то так уже делал в реальности? Есть примеры?
Скрипт сообщает, что вот эти теги и вот эту геометрию рассматривать как линию/полигон. Ваш же не смущает как это мультиполигон из отрезков превращается в полигон.