Проще говоря какой тег я должен добавить чтобы мои мультиполигоны считались “Нового стиля” ?
Вроде как теги на отношение, а не на линии.
У него нет тегов, он хранит геометрию-фикцию. Небось ещё и ссылки на них в виде номеров релейшенов использует О_о. Стоит заметить, что ни ситигид тогда, ни гислаб сейчас не хранят полигоны обрезки для себя в ОСМ, и только Костик тут без этого никак обойтись не может.
Фикции в базе не место.
The plan is not to simply “remove” old style multipolygons. The plan is to change them into new style multipolygons, which are fully (even better) supported by all editors and other OSM software. This means that normally, the change should only have advantages and no disadvantages.
The change from “old style” to “new style” multipolygons is a subset of actions discussed in this February 2017 thread on the talk email list:
https://lists.openstreetmap.org/pipermail/talk/2017-February/077543.html
Bye
Frederik
But what about situation when inner=way2 have different properties (tags) and natural=wood at the same time? It can be leaf_cycle=* and/or leaf_type=* for example (or any other tags).
Такое ощущение, что народ из спячки выходит и панику разводит. Нет ни каких фантастических условий, главное и единственное, что теперь мультиполигон должен быть объектом, т.е. помимо type=multipolygon должны быть ещё теги обозначающие объект. До тегов составных частей ему дела нет. Это как раз раньше надо было понять, что если на всех кусках есть wood - то наверное я лес. Теперь от этого избавились, теги должны быть явно на отношении.
А note и type=multipolygon уже не теги? Там где был ещё и note:de ни один не был удалён. Поэтому я и на остальные его дабавил, профит! Мультиполигон нового стиля готов! 
Нет, никакой osm сущности этот объект не несёт, note можно вообще безболезненно удалить.
Поднимал этот вопрос (конкретно по лесам) ранее. В том и проблема, что «есть дело до тегов». В том смысле, что они игнорируются для inner, если там обнаруживается совпадающий с отношением natural=wood (+доп. теги, явно выделяющие inner на фоне всего мультиполигона леса). «Избавились», не подумав о нюансах/исключениях, которые, на мой взгляд, очевидны: смешанный лес может (и это факт) состоять из массивов деревьев различных видов. Лес имеет участки со старым древостоем и молодняком, редким и густым может быть. В лесу могут быть насаждения (на местах вырубок, например) и т. д., куча вариантов. Так что теперь — отказываться от мультиполигонов и переходить на «лоскутный» метод?
Вы себе что-то придумали, мультиполигону нет дела до тегов дырки, она на то и дырка.
Нет.
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, особенно которые можно склеит в один объект? Это наверное облегчает мапинг 