Хотел бы напомнить, что OpenMapSurfer не поддерживает здания сложной формы. Алгоритм реализовывался на рассвете 3д в ОСМ, поэтому реализованы только объекты с первоначальным тегированием, не содержащие building:part и каких либо отношений
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-тегирования не должны содержать положений, которые впоследствии могут привести к невозможности однозначной трактовки данных при одновременном соблюдении озвученных требований.
Хорошо, если неидеально затегированное здание и так хорошо отображается в каких-то рендерах. Но ситуаций, когда затегированные без нарушений рекомендаций здания нельзя нормально отрисовать, наверное-таки быть не должно. Поэтому считаю необходимым обозначить требование непересечения частей.
Подобного обсуждения, может, раньше и не было. Однако, надеюсь, ещё не поздно его начать.