Можно сделать упрощённое подобие этой карты. В точности нарисовать то же самое не хватит аппаратных ресурсов навигатора и его изобразительных средств. Но точечных объектов можно отобразить больше.
А разве это не часть проекта 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? Кто-то так уже делал в реальности? Есть примеры?
Скрипт сообщает, что вот эти теги и вот эту геометрию рассматривать как линию/полигон. Ваш же не смущает как это мультиполигон из отрезков превращается в полигон.
Я более детально углубился в вопрос. Оказывается, этот скрипт используется в openstreetmap-carto как более продвинутый аналог стилей. Но только проблема в том, что в этот скрипт нужно конвертировать все стили сразу, фильтровать им только cliff и earth_bank не получится. Но на такой эксперимент на продакшне я сейчас не готов, да и времени на это пока нет. И тесты по производительности нужно делать. Тем более, что нельзя сказать, будто это решает серьёзную проблему. Я уважительно отношусь к вашему мнению, freeExec, но мне кажется, что если пока в wiki описаны все особенности отрисовки natural, natural=cliff и natural=earth_bank, это и проблемой-то не является и не является рисованием под рендер. Но я понимаю, что с такой фильтрацией просто удобнее, хотя бы будет меньше вопросов от плохо читающих документацию пользователей, и со временем я, наверное, её сделаю, если импорт со скриптом не будет потреблять намного больше ресурсов.
Мне непонятна другая вещь. Например, в русскоязычной wiki указано, что cliff может быть и полигоном. И этот посыл поддержан, например, в сборке для garmin у ValentinAK. Там реально рисуется полигон с камешками. Может быть, natural=сliff рано удалять из полигонов?
Вообще, из здравого смысла, обрыв - все-таки линейный объект. Cliff-полигон это какой-то древний костыль для обозначения площади, занятой камнями. Но есть же natural=scree для свободных камней и natural=bare_rock для прикрепленных, и даже устаревающий natural=bedrock.
Заметил, что с тегами просеки man_made=cutline cutline=section линия просеки рисуется без обводки, а дорога (highway=path) - с обводкой.
Понимать так: просека - это просто просека и для нее достаточно пунктирной линии, а для дороги это дополнительный тег, что мол широко прорублен лес?
По вики cutline используется только для прямых линий просек, никак не для дорог, что в Ru, что в En.