1 к1 затегирован неправильно: на 9-тиэтажном здании стоит building:levels=7.
на доме (building) в любом случае должно стоять building:levels=9, т. к. существует часть дома, имеющая building:levels=9
части дома (building:part) можно затегировать двояко:
2а) здание разрезается по вертикали (на building добавляется building:parts=vertical), получается три building:part-s (здесь и далее под building:part-s подразумевается два или более building:part=, не путать с тегом building:parts=, который ставится совместно с building=): на двух (крайних) building:levels=7, на третьей (средней) - building:levels=9
2б) здание разрезается по горизонтали (на building добавляется building:parts=horizontal), получается два building:part-s: на первой (нижней) - building:levels=7, на второй (верхней) - building:levels=9 + building:min_level=7.
В приведённой схеме есть части пространства, относящиеся к нескольким 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 было бы конечно логично. Но не стоит. Для обратной совместимости на отдельный контур 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-тегирования не должны содержать положений, которые впоследствии могут привести к невозможности однозначной трактовки данных при одновременном соблюдении озвученных требований.
Хорошо, если неидеально затегированное здание и так хорошо отображается в каких-то рендерах. Но ситуаций, когда затегированные без нарушений рекомендаций здания нельзя нормально отрисовать, наверное-таки быть не должно. Поэтому считаю необходимым обозначить требование непересечения частей.
Подобного обсуждения, может, раньше и не было. Однако, надеюсь, ещё не поздно его начать.
Felis Pimeja, не смотря на замечательную «разжёванную» схему, не могу «переварить» информацию
Предлагается мультиполигоны здания, составленные из кусочков-отрезков (на схеме - 4 мультиполигона part=yes+1 объединяющий part=no) завернуть ещё и в отношение? Или - как вариант - накладывающиеся, но не пересекающиеся полигоны (на схеме - 4 прямоугольника, вписанных в 5-й многоугольник) объединить отношением?
Если верны предположения выше, то первое - бессмысленное какое-то масло масляное, переусложняющее дело. Второе - неплохой вариант упрощения процесса 3-d тегирования.
2 LLlypuk82:
Все части относящиеся к отдельному зданию предлагается обернуть в отношение type=building. Дабы показать, что “все эти кирпичики составляют единое целое”
Так разве мы не получаем набор мультиполигонов, вписанных в объединяющий их «мастер»-мультиполигон с building:part=no и адресацией?
Мне показалось оправданным внедрение объединяющего отношения type=building именно для исключения кучи мультиполигонов. А иначе не понимаю смысла такого нагромождения/усложнения. Только для явного отражения этого «объединяющего» момента посредством role? Чем плох теперешний вариант, где это отражено через общий контур, который так и так необходим?