Вы себе что-то придумали, мультиполигону нет дела до тегов дырки, она на то и дырка.
Нет.
type задаёт что это мультиполигон, а note -это просто комментарий для маппера. Есть и другие “нетеги” - created_by, source и т.п.
Нужны теги, обозначающие саму сущность, а их нет. Вот если бы были какие ни будь теги типа processing=cutting/cutting=navitel - это уже было бы что-то, особенно если запилить страничку в вики про них.
Но мне тоже кажется что этим сущностям не место в общей базе.
Добрый день, чет у меня подгорело с модных мультиполигонов для навитела. В чем проблема их локально хранить и поддерживать? Чем ЭТО отличается от name=Мой дом? Как это быстро удалить из базы если кто - то забросит конвертацию в навител?
Вот то, про что говорит LLlypuk82:
Кусок леса, где растут лиственные деревья:
http://www.openstreetmap.org/relation/5441395#map=16/55.8244/37.7394
Внутри этого куска есть хвойные посадки:
http://www.openstreetmap.org/relation/5441403#map=16/55.8244/37.7394
И эти посадки приходится объединять в мультиполгион (хотя практически, это нахрен не нужно), потому что если на каждый отдельный inner большого мультиполигона http://www.openstreetmap.org/relation/5441395 просто повесить свои теги natural=wood, они будут игнорироваться, как ошибочные. Требование такого костыля банально усложняет маппинг.
Не знаю, что значит “чет у меня подгорело”, это какой-то непонятный жаргон, но по сути вопроса - согласен: эти контуры для обрезки - всего-навсего техническая информация, не обозначающая никакие реальные или условные объекты, которую не только можно, но и нужно хранить локально. Это, кроме всего прочего, еще и надёжнее - никто их не сломает. Единственный аргумент за хранение их в базе - лень того, кто их использует. Никаких других просто не существует.
Локально можно хранить только файлы poly, которые создаются из мультиполигонов. Если в базе нет мультиполигона - значит poly начнет устаревать и рано-поздно пострадает обрезка. Всё просто.
Теоретически (с большими поправками) можно собирать полигоны обрезки из нескольких нормальных областных (или районных) мультиполигонов, делается это настройкой getbound. Но он иногда делает артефакты. Я как-то писал Лёше года 3-4 назад но ничего не правилось.
А как проблемы конвертера стали проблемами OSM. Да и не думаю что области прям уж так плавают и делаются новые города. В любом случае поддерживать что - то. Тем более без тегов вменяемых я бы вообще удалил все, если бы не увидел тему на форуме.
С чего это вдруг? Главное чтобы большой мультиполигон был непустой, теги для inner-ов должны обрабатываться независимо от его наличия.
Это не проблемы конвертера, это обычный компромисс. Есть две крайности -
- потратить всё своё время на поддержание локальной базы полигонов обрезки в актуальном состоянии 2) прекратить конвертацию
Поэтому сейчас используется третий вариант 3) хранить полигоны обрезки в текущем виде, до тех пор пока не появятся альтернативы (например вы поможете улучшить osm-getbound.pl)
PS:
4) нарезать Россию по BBOX (правда недовольных будет на порядок больше )))
Кем игнорируются?
Ну и пример мягко говоря странный, зачем там вообще нарезка из кучи outer, особенно которые можно склеит в один объект? Это наверное облегчает мапинг 
Это вопрос к ответственным за рендеринг (в данном случае — mapnik)
Реальность такова, что они так не обрабатываются в случае, когда основной тег на отношении совпадает с таковым на inner-ах.
Процедурой рендеринга картостиля mapnik. Поскольку «…The plan is that in the near future, osm2pgsql - and thereby also the map style on www.openstreetmap.org - will stop supporting “old style multipolygons”…»
BushmanK привёл пример. Добавлю текста: если сосновый бор оброс вокруг листопадными деревьями, а весь этот массив обозначен (как и положено) мультиполигоном, на котором (на отношении) указан свой тип листьев (в довесок к natural=wood), а на бору (который inner) — свой тип листьев (+natural=wood), то бор будет белым пятном посреди лиственного леса.
Не понимаю, что здесь сложно для понимания проблемы, а это проблема.
Вы таки не путайте то что есть сейчас и то что будет. Или где-то уже есть новый рендерер?
Насколько я понимаю, основная цель убирания поддержки “old style multipolygons” - это как раз исправление подобных глюков, т.к. для их поддержки приходилось использовать теги не самого мультиполигона, а его частей.
Если поддержку выкинут - части станут независимыми от мультиполигона, и всё должно рисоваться корректно.
Чистка проводится именно под это правило. А рендеринг уже сейчас «не поддерживает» (игнорит) то, о чём речь выше. И не будет поддерживать, потому что официально объявлено: см. цитату. Так что ничего не изменится (кроме удаления тегов с inner, что является проблемой и ею останется тем более, что это — целенаправленное действие, а не глюк или ошибка)
P. S. Надеюсь, woodpeck меня понял (*если читал)
Именно так. Если сейчас сделать мультиполигон natural=wood leaf_type=broadleaved, в котором с ролями inner будут way-и natural=wood leaf_type=needleleaved (а не другой мультиполигон, который объединяет все эти контуры, и на который повешены natural=wood leaf_type=needleleaved), мапник свойства inner-ов будет игнорировать, а алгоритм чистки мультиполигонов это, на сколько я понимаю, тоже будет считать ошибочным, потому что natural=wood висит и на мультиполигоне, и на way-ях, которые входят в него с ролью inner.
В моем примере, все хвойные “дырки” (посадка там имеет вид шахматной доски, потому там и “нарезано”) пришлось объединить в мультиполигон и присвоить natural=wood leaf_type=needleleaved именно ему. Иначе и валидатор JOSM ругается, и Mapnik это не умеет рендерить, и вот новое правило чистки это будет считать ошибкой.
freeExec, не ёрничайте, а разберитесь сначала, о чем идет речь.
Вы как-то слишком усложняете официальную цитату, в ней нигде не приведено обязательство отсутствия каких-либо тегов на членах отношения.
Сейчас в osm2pgsql реализован хитрый алгоритм, который умеет переносить теги с внешнего контура на весь мультиполигон. Этот костыль планируется выкинуть и унифицировать, т.е. на самом деле упростить и создавать все полигоны и мультиполигоны, у которых есть нужный триггер (например тег wood).
Можете дальше развить мысль и представить почему началась “зачистка” (для того чтобы в базе osm2pgsql на одном месте не получилось два полигона - один с дыркой, а второй без дырки).
(added)
получается я другими словами пересказал
Я то разобрался. А вот у вас свойства иннеров почему-то обрабатывает мапник, а не osm2pgsql или другие.
Но дабы не отдаляться от темы я взял тот пример, удалил мултиполигон, объединяющих дырки в один, и назначил шахматной доске, каждому квадрату, роли с удалённого отношения. Ну то есть сделал то, что по вашим словам не работает.
Как видно темные куски леса, которые самостоятельные полигоны, рендерятся без проблем. Так же на верхнем куске текущий вариант, и тоже с ним проблем нет. Но он намного сложнее в поддержке из-за вхождения куска в два отношения.
Приведённый пример woodpeck был совсем о другом - как следует исправить со старого стиля на новый для корректной отрисовки после прекращения поддержки старого. Для того и предлагается делать это руками вместо автомата, чтобы не испортить подобные случаи, где автомат легко может налажать.
В текущем рендеринге как раз проблемы из-за поддержки старого стиля полигонов, пример:
https://trac.openstreetmap.org/ticket/2853
https://github.com/openstreetmap/osm2pgsql/issues/185
После его отключения подобные проблемы должны уйти.
Мапник вообще не знает ни про какие inner/outer-ы, он работает с подготовленной геометрией в базе. А что именно сформируется из данных - определяется логикой osm2pgsql, который её заполняет. Сейчас там анализируется вхождение в пустые мультиполигоны и если таковые есть - делается перенос тегов с outer на объект геометрии, а сами member-ы выкидываются. Из-за этого выкидывания и возможны разнообразные проблемы.
Убирание поддержки, насколько я понимаю, заключается в выкидывании этого куска кода нафиг. И ничего игнорироваться не будет.
Мда.
Под “мапником” я подразумеваю всю конструкцию, отвечающую за рендеринг стандартного стиля. И речь не о том, возможно ли теоретически это где-то рендерить (конечно, возможно). А о том, что такова “политика партии”, которая выражается в том, как работает стандартный стиль, на что ругается валидатор JOSM и какой способ разметки будет считаться “кошерным” в ситуации, о которой идет речь, когда inner-ы - тоже лес, но другой.
Мда…
josm не ругается, osm2pgsql переваривает, mapnik рендерит. Наверное не в той партии состоите. Ну а караван продолжает идти не смотря ни на кого.
О, это великое искусство донесения информации до другого человека…
osm2pgsql может делать всё, что угодно. Но если предварительно будут удалены теги с inner-членов отношений-лесов, то никакая версия osm2pgsql ничего не сможет «показать» по той причине, что там нечего будет показывать, потому что всё почищено, потому что так решили сделать специально. И это следует напрямую из приведённого woodpeck примера, где чётко показано, как будет работать вся схема (чистки, обработки и т. д.)
До сегодняшнего дня считал, что владею русским языком в достаточной степени, чтобы доводить простые (как мне кажется) мысли до кого-либо…
P. S. Вот на месте старой вырубки »вырос молодой лес« (подлесок, не знаю, как оно правильно, но по снимку отличие явное). Неважно, какие именно отличия будут и какие теги. Важно то, что с ними будет непонятно что. Рядом есть насаждения (у которых, к примеру: другой возраст, другая плотность, другое происхождение, другой вид). Но всё это не учтено и как бы не планируется (и даже подчищается, как мы узнаём теперь)
На месте вырубки высажен новый лес. Он отличается от окружающего? Да. Он должен быть «белым пятном»? Нет. (сейчас этот кусок никак не затегирован, если что, в отличие от предыдущего, но выглядят на мапнике они одинаково)