Кстати, на SOTM-Baltics был весьма интересный (для любителей третьего измерения) доклад
Micromapping and 3D modelling (Marek Kleciak)
искать тут http://sotm-baltics.org/schedule.html
Кстати, на 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 и каких либо отношений
Угу. Хотел отдельно рассказать про особенности разных 3Д рендеров, но что-то как всегда в лимит времени не уложился.
Вот тут кто неправ, F4 Map или мапер?
Вот панорама.
И таких мест много, мне непонятно, зачем здесь building:min_level?
1 к1 затегирован неправильно: на 9-тиэтажном здании стоит building:levels=7.
Ага, спасибо за понятное объяснение. Сам трогать (пока) не буду, приболел немного
Если я правильно понял суть всех наших последних обсуждений, то наиболее оптимальный вариант тегирования в общем случае выглядит так:
Dinamik, я ставляю за скобками building:parts. В остальном, поправь если что-то упустил.
В свете продвижения релейшена 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-тегирования не должны содержать положений, которые впоследствии могут привести к невозможности однозначной трактовки данных при одновременном соблюдении озвученных требований.
Хорошо, если неидеально затегированное здание и так хорошо отображается в каких-то рендерах. Но ситуаций, когда затегированные без нарушений рекомендаций здания нельзя нормально отрисовать, наверное-таки быть не должно. Поэтому считаю необходимым обозначить требование непересечения частей.
Подобного обсуждения, может, раньше и не было. Однако, надеюсь, ещё не поздно его начать.