Здания переменной этажности

Кстати, на SOTM-Baltics был весьма интересный (для любителей третьего измерения) доклад
Micromapping and 3D modelling (Marek Kleciak)

искать тут http://sotm-baltics.org/schedule.html

А строительство то как красиво рендериться!

Записал небольшой скринкаст по 3D. Завсегдатаи темы вряд ли найдут для себя что-то новое. Но пущай будет.

Насколько я понимаю, несколько building:part (например, перемычка между башнями) оказались не включены ни в одно из building. Также, с одной стороны, получалось, что бизнес-центр располагается только на первых пяти этажах здания, а с другой - что у него есть две высоких башни.

Они все по умолчанию считаются принадлежащими контуру здания внутрь которого попадают. То есть стилобатная часть является отправным элементом. Адрес и пр. можно вешать на неё. Хотя это конечно большое допущение. И есть предложение собирать все части в одно отношение type=building. Мне оно кажется вполне здравым. Но его пока никто не поддерживает (даже страницы отдельного пропозала нет) поэтому адресная часть будет потеряна. С башен можно было бы снять building=yes. Я оставил лишь для того, чтобы мапник нарисовал их контуры поверх стилобата (угу, доставайте ваши тухлые помидоры :)).

К сожалению, эта схема не работает для http://www.openmapsurfer.uni-hd.de/?zoom=18&lat=55.79698&lon=37.53916&layers=B000000FFFF

Я немного по другому мапил и у меня вышло нарисовать более простое здание
http://www.openmapsurfer.uni-hd.de/?zoom=18&lat=48.47772&lon=35.03682&layers=B000000FFFF

Хотел бы напомнить, что OpenMapSurfer не поддерживает здания сложной формы. Алгоритм реализовывался на рассвете 3д в ОСМ, поэтому реализованы только объекты с первоначальным тегированием, не содержащие building:part и каких либо отношений :frowning:

Угу. Хотел отдельно рассказать про особенности разных 3Д рендеров, но что-то как всегда в лимит времени не уложился.

Вот тут кто неправ, F4 Map или мапер?
Вот панорама.

И таких мест много, мне непонятно, зачем здесь building:min_level?

1 к1 затегирован неправильно: на 9-тиэтажном здании стоит building:levels=7.

  1. на доме (building) в любом случае должно стоять building:levels=9, т. к. существует часть дома, имеющая building:levels=9
  2. части дома (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.

Ага, спасибо за понятное объяснение. Сам трогать (пока) не буду, приболел немного :frowning:

Если я правильно понял суть всех наших последних обсуждений, то наиболее оптимальный вариант тегирования в общем случае выглядит так:

Dinamik, я ставляю за скобками building:parts. В остальном, поправь если что-то упустил.

  1. В приведённой схеме есть части пространства, относящиеся к нескольким 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).
  2. Из схемы не очень понятно, сколько существует линий c building:levels=7. Хотелось бы как-то явно обозначить, что нужно делать не один мультиполигон с двумя внешними outer, а два полигона/мультиполигона с одним outer каждый.
  1. А разве где-то упоминается, что части не должны/не могут пересекаться?
  2. Согласен. В последнее время этот вопрос звучит часто. Подправил, перезагрузил картинку.

В свете продвижения релейшена 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-тегирования не должны содержать положений, которые впоследствии могут привести к невозможности однозначной трактовки данных при одновременном соблюдении озвученных требований.

Хорошо, если неидеально затегированное здание и так хорошо отображается в каких-то рендерах. Но ситуаций, когда затегированные без нарушений рекомендаций здания нельзя нормально отрисовать, наверное-таки быть не должно. Поэтому считаю необходимым обозначить требование непересечения частей.

Подобного обсуждения, может, раньше и не было. Однако, надеюсь, ещё не поздно его начать.