Ага, спасибо за понятное объяснение. Сам трогать (пока) не буду, приболел немного 
Если я правильно понял суть всех наших последних обсуждений, то наиболее оптимальный вариант тегирования в общем случае выглядит так:
Dinamik, я ставляю за скобками building:parts. В остальном, поправь если что-то упустил.
- В приведённой схеме есть части пространства, относящиеся к нескольким building:part. Например, на уровне 1-го этажа под контуром building:levels=6 есть building:part=yes + building:levels=1 и другой building:part=yes + building:levels=6. Под контуром с building:levels=7 на уровне 2-6 этажей есть наложение двух building:part (building:part=yes + building:levels=6 и building:part=yes + building:levels=7), а на уровней 1 этажа аж трёх (building:part=yes + building:levels=1, building:part=yes + building:levels=6 и building:part=yes + building:levels=7).
- Из схемы не очень понятно, сколько существует линий c building:levels=7. Хотелось бы как-то явно обозначить, что нужно делать не один мультиполигон с двумя внешними outer, а два полигона/мультиполигона с одним outer каждый.
- А разве где-то упоминается, что части не должны/не могут пересекаться?
- Согласен. В последнее время этот вопрос звучит часто. Подправил, перезагрузил картинку.
В свете продвижения релейшена type=building, теги addr:housenumber куда вешать: на линию/релейшен с ролью outline или добавлять в свойства самого родительского релейшена type=building?
Ни в коем случае не на релейшен type=building. Его еще толком никто не понимает.
Угу. На релейшен type=building было бы конечно логично. Но не стоит. Для обратной совместимости на отдельный контур building=yes, включённый как outline.
В случае, если часть пространства принадлежит нескольким building:part-s с разными параметрами, непонятно, как это трактовать. Если один building:part имеет building:levels=1 и building:facade:material=wood, а второй building:part с той же проекцией на горизонтальную плоскость имеет building:levels=2 и building:facade:material=steel, как ответить на вопрос, из какого материала сделан фасад на уровне 1-го этажа? Мне кажется, требование неналожения в пространстве частей разных building:part-s вытекает из общих соображений, здравого смысла, требований разумности, однозначности данных (пытаюсь подобрать нужные слова)…
Полагаю, параметры, характеризующие здание, должны указываться на традиционном building, но при этом могут и дублироваться в отношении type=building.
Хороший пример. Но ведёт к усложнению разбивки модели на элементы. И мне кажется, что если продолжать размышлять в том же направлении то можно договориться до совсем мелкого членения объёмов с целью показать полоски разных цветов/материалов на фасаде. Я утрирую, конечно. А нет ли где-нибудь более развёрнутых обсуждений этого вопроса?
Доп: дабы не быть голословным:
Мне казалось, что в OSM где-то уже экспериментировали с кусками фасада разного цвета:P
Спору нет: дополнительные требования усложняют реальное наполнение базы данных, но ведь и затегировать 3D-здание в принципе куда сложнее, чем ограничиться building=yes и addr:housenumber=1:rolleyes:
Полагаю, что рекомендуемые правила 3D-тегирования не должны содержать положений, которые впоследствии могут привести к невозможности однозначной трактовки данных при одновременном соблюдении озвученных требований.
Хорошо, если неидеально затегированное здание и так хорошо отображается в каких-то рендерах. Но ситуаций, когда затегированные без нарушений рекомендаций здания нельзя нормально отрисовать, наверное-таки быть не должно. Поэтому считаю необходимым обозначить требование непересечения частей.
Подобного обсуждения, может, раньше и не было. Однако, надеюсь, ещё не поздно его начать.
Это как же, вашу мать, извиняюсь, понимать? 
http://map.f4-group.com/#lat=59.9596371&lon=30.3385146&zoom=18&camera.theta=79.427&camera.phi=35.627&la=la
Эцелоп:
Есть тема по F4. там разработчик очень бойко отвечает на такие вопросы:
http://forum.openstreetmap.org/viewtopic.php?id=21489
Можно его спросить:
Please pardon my French, but what the fuck is it?
Please have a look at our wiki page that explain how we handle “building” and “building:part” tags.
Sorry to answer here in English but i don’t speak Russian.
Best regards.
Это следует понимать как ошибочно затегированное здание: не выполняется условие: building должно включать в себя все составляющие его building:part-s
You took the lead over me;)
Блин, а я думал, что косяк в том, что он стоит на воде.
Felis Pimeja, не смотря на замечательную «разжёванную» схему, не могу «переварить» информацию 
Предлагается мультиполигоны здания, составленные из кусочков-отрезков (на схеме - 4 мультиполигона part=yes+1 объединяющий part=no) завернуть ещё и в отношение? Или - как вариант - накладывающиеся, но не пересекающиеся полигоны (на схеме - 4 прямоугольника, вписанных в 5-й многоугольник) объединить отношением?
Если верны предположения выше, то первое - бессмысленное какое-то масло масляное, переусложняющее дело. Второе - неплохой вариант упрощения процесса 3-d тегирования.
Исправил согласно данным рекомендациям, вроде на F4 обновилось, но лучше не стало, не пойму, где “косяк”.
Ссылка на контур.
2 LLlypuk82:
Все части относящиеся к отдельному зданию предлагается обернуть в отношение type=building. Дабы показать, что “все эти кирпичики составляют единое целое”
Вот здесь косяк: building:parts=yes
Так разве мы не получаем набор мультиполигонов, вписанных в объединяющий их «мастер»-мультиполигон с building:part=no и адресацией?
Мне показалось оправданным внедрение объединяющего отношения type=building именно для исключения кучи мультиполигонов. А иначе не понимаю смысла такого нагромождения/усложнения. Только для явного отражения этого «объединяющего» момента посредством role? Чем плох теперешний вариант, где это отражено через общий контур, который так и так необходим?
Спасибо, я всю голову сломал, даже проверял теги и значения на символы из другой раскладки, а эту “s” не заметил.