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

это возможно, если переделать растровый стиль онлайн-тайлов в стиль отображения карт гармин. затраты времени и труда сами понимаете большие.

karnavalny это не особенность осм, тот же рендер джосма показывает все правильно :slight_smile: это особенность схемы осм реализованной в базе postgresql :slight_smile:

И что же, куда из базы делось направление :slight_smile:

И потом, хотя по-умолчанию объекты 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, для рендеринга это совершенно без разницы.

Добрый день.
Не могли бы вы добавить отображение названий болот: natural=wetland.
Заранее большое спасибо !

да так и сколь помню было сделано. но гармин етрекс легенд потерян давно и теперь не скажу :slight_smile:

нет. если быть точным, проект осм заканчивается на выгрузке planet.osm.xml на сайте http://planet.openstreetmap.org :slight_smile:
только сбор, хранение и выгрузка геоданных.
всё остальное - вселенная сторонних проектов связанных (и не очень) с опенстритмап, безграничная и динамичная.
даже тайлы с опенстримап.орг, которые все и принимают за осм, не являются частью проекта :slight_smile:

Емнип это osm2pgsql нормализует полигоны, чтобы outer и inner были в противоположных направлениях. Сейчас точно не помню, какое направление является стандартом по-умолчанию CW или CCW.

В этом плане imp2osm намного гибче (и быстрее), но он полностью поменяет структуру базы и потребует переписать все SQL-запросы в рендере.

Это хорошая идея, спасибо. Сделаю.

У меня режим по умолчанию, т.е. без поддержки postgis’овских мультиполигонов.

Спасибо за инфо, я посмотрю.

Так и я написал, нет нужды создавать из earth_bank полигоны.
https://github.com/openstreetmap/osm2pgsql/blob/master/docs/lua.md

А в одну сторону они потому, что база оперирует кольцами и для них имеет значение направление. Потому что внешнее кольцо должно быть направлено в одну сторону, а внутренняя дырка в другую.

Возможно, но это странно, поскольку:


opentopomap=# select  count(*) from planet_osm_polygon where ST_NumInteriorRings(way) > 0;
 count  
--------                                                                                                                                                                                                                                                      
 335205                                                                                                                                                                                                                                                       
(1 строка)

То есть всего лишь 0.73% полигонов в базе имеют дырки.

P.S. Поскольку внятной документации на osm2pgsql нет, желающие могут более подробно изучить исходники этой программы, и найти там ответ. :slight_smile:

Я воздержусь от подобного скрипта. Это может принести гораздо больше проблем, чем пользы. Мне кажется, что пользователь должен уметь пользоваться area=no или резать линии, в зависимости от контекста, тем более это есть в документации.

area=no избыточен, ибо семантика тега уже наделяет его свойством линейности. И корректная обработка данных возложена на потребителя. Это что называется - мапить под рендер.

Ок, на вскидку, не сильно погружаясь в тему скриптов и прочее. Есть inner в полигоне, нарисованный замкнутой линией, который пользователь отметил ещё и как, скажем, cliff. Так что это, линия, или вложенный полигон? Как тут отличать?

Так это два разных объекта, для cliff это внешний контур. Когда у вас в дырке леса озеро, оно же синим заливается, а не лесом.

Как я понял из документации, cliff - это точка, или линейный объект. https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff Или где-то ошибка? Но на его месте может быть earth_bank, например. :slight_smile:

Не совсем понял вопроса. Но дополню по предыдущему. Это в ОСМ одна геометрия для двух объектов - для одного это дырка, для другого это основной контур. А в базе это уже два совершенно разных объекта - один объект с дыркой, а второй лежит поверх дырки. И в данном случае он вполне может быть не полигоном на дырке, а только её контуром, от этого первый объект никак не затрагивается.

Но изначально эта линия-дырка ведь имеет один 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 рано удалять из полигонов? :slight_smile:

Вообще, из здравого смысла, обрыв - все-таки линейный объект. Cliff-полигон это какой-то древний костыль для обозначения площади, занятой камнями. Но есть же natural=scree для свободных камней и natural=bare_rock для прикрепленных, и даже устаревающий natural=bedrock.

И вообще в англовике: https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff
нет площадных обрывов.