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

Это я и подразумевал, суть не меняется (не важно как называть: «внешний контур» или «граница здания», собственно внешний контур всегда и принимается за основной контур/границу здания, куда и ставится максимальная этажность)

На такие не стоит равняться, а для плоских - всё равно.

Стоп, откуда взялась зелёная часть? Простите за въедливость, но это - непонятка. Вы подразумеваете такую схему по умолчанию (мол, и так же ясно), а рисуете только (не знаю что «только» )… что вы рисуете именно в 11-м примере? С этой картинкой (где появился зелёный элемент) всё понятно, только зачем тогда мультиполигон? Вы же сами выступаете за упрощение.
Мне ещё интересно: всем остальным всё понятно (о чём я так настойчиво спрашиваю)?
Если у вас подразумевается, что мультиполигон состоит из зелёного и синего многоугольника, то причём там role=inner/outer? Как они возникают (в результате на красном и синем контруре)?

Тогда накой указывать в общем полигоне этажность здания?

Здесь я бы поставил на красный контур building=apartments, building:levels=9, roof:levels=1, на зелёный контур -** building:part=yes, building:levels=11, building:min_level=10**.

Может быть для того, чтобы простенькие рендеры, которые не понимают building:part и рисуют только building:levels тоже могли хоть как-то нарисовать здание? Для той же девятиэтажки с лифтовой надстройкой, которая выполнена с помощью building:part это будет достаточно.

О том и речь, что не надо.

Они в любом случае нарисуют неправильно. Либо завысят либо уменьшат этажность соответствующих частей зданий.
Может стоит поддерживать корректность хотя бы где-то, чем везде наполовину? (при том, что и так наполовину всё работает сейчас и будет дальше, вне зависимости от принимаемых изменений по схеме объёмных зданий)

f4map изобразит в таком случае левитирующую надстройку с “выщербиной” под ней до уровня земли. Но это ладно.
А где какую height будем ставить?

И ещё один вопрос: как смотрит сообщество на возможность введения отдельного тега для высоты и этажности для частей здания?
Например - для зданий - building:levels и building:height
а для building:part - levels (и min_level); height (и min_height)
Есть ли ещё прецеденты, чтобы одно и то же обозначалось разными тегами в зависимости от контекста?
(по поводу “зачем это надо”:
во-первых, для возможности сбора статистики по зданиям;
во-вторых, чтобы чётко отделить 3d-навороты от обычной 2d карты;
в третьих - для упрощения прорисовки зданий с надстройками: http://img-fotki.yandex.ru/get/6846/51351719.14/0_a54ec_2aada80e_orig )

Возьмём обычную девятиэтажку:

Представим сферический рендер, который не понимает building:part (через которую сделана надстройка), а понимает только building:levels. Или же представим будущее с единорогами, в котором есть конвертер в формат Навител карт nm7, который поддерживает 3D-здания с одинаковой этажностью. Этим программам пригодилось бы число этажей на контуре здания.
Я не говорю, что этажность нужно ставить на все контуры. Но на некоторые - точно. По крайней мере там, где building:part незначительны и находятся сверху здания (те самые технические надстройки). Что думаете?

Если цифры на картинке правильные, то на красный контур - height=30, на зелёный - ** height=33 + min_height=30**

Я обеими руками за. Что-то вроде такого:
Для здания:
building:levels - этажность (как сейчас)
building:min_levels - минимальная этажность (как сейчас)
building:height - высота, чтобы всё было в namespace-e
Тег height используется не только в зданиях, поэтому не знаю, стоит ли выделять его в namespace building
Для части здания:
building:part:levels - этажность
building:part:min_levels - минимальная этажность

А ещё мне не нравится само building:part, потому что part - не свойство тега building, а отдельный тег. Поэтому они не должны быть отделены двоеточием. Должно быть building_part, я считаю.

И, раз уж заговорили об этом, я бы поменял building:levelPlan на building:level_plan для однородности со всеми другими тегами. Или вообще на building:levels_plan

Кажется тема снова заглохла. Где же все мапперы, которые рисуют building:part? Неужели их устраивает нынешняя ситуация, полная
неоднозначностей?
В общем, скажу так. Многим не вполне ясно, почему тема тегирования разноэтажных зданий всплывает вновь и вновь. Проблема
заключается в том, что правила зачастую придумывают люди, которые не занимаются практикой. И когда дело доходит до дела, выясняется, что чтобы сделать что-то простое, надо совершать множество неочевидных, спорных действий.
Чтобы было понятно: начнём с азов.
Возьмём самое обычное многоэтажное жилое здание. Что представляет его форма? Параллелепипед, т.е. коробку. Крыша его или плоская,
или четырёхскатная, или двухскатная. Прочие варианты встречаются редко. На крыше обычно стоят коробки поменьше - технические
надстройки. Если крыша неплоская, они обычно скрываются под ней (если высокие - могут частично вылезать). Если же плоская - всё на
виду.
На этажность здания эти коробки, так и быть, не влияют (чердаки за этаж не считаются). Поэтому поговорим пока про высоту (height), хотя с этажностью у разноэтажных зданий возникают точно такие же проблемы.
Итак, при учёте общей высоты, надо считать все капитальные части здания. Включая лифтовые надстройки (на спутнике видны как
квадратики над каждой парадной), выходы вентиляции (длинные узкие стены на крышах хрущёвок), и ограждения крыши (снаружи часто
выглядят как продолжение стен; могут быть от полуметра до пары метров высотой; могут быть как с торцов, так и по всему периметру
крыши).
В большинстве случаев, общая высота здания с учётом всех этих надстроек, на 2-3 метра больше, чем уровень крыши. Хотя иногда бывают
и многоэтажные надстройки. Но возьмём самый простой вариант. Пусть надстройка одна, мы её отметили. Её высота - 32, уровень крыши -
29. Мы выставили height=32 на квадратике надстройки. Что будем отмечать на контуре здания? 29? Но это внесение ложных данных, ведь
общая высота здания включает высоту надстройки и равна 32. 32? Но если мы так сделаем, ни один рендер не узнает, что высота крыши -
29, и нарисует просто коробку высотой в 32 метра без детализации.

Проблема ясна? Надеюсь, да. Теперь, что можно сделать? Будем реалистами и не станем рассматривать варианты, требующие коренной
переделки схемы тегирования. Например, вариант с введением нового отношения всё равно никто не будет поддерживать.
Тогда я вижу всего два выхода.
Первый не требует никаких нововведений. Просто нужно создать два объекта на контуре здания. Первый объект - “здание” с высотой 32
метра. Второй объект - “часть здания” высотой 29 метров. По крайней мере один из этих объектов придётся сделать мультиполигоном, и
повесить на контур здания как на единственный outer. Иного выхода нет. В итоге всё рисуется, все довольны. Но… хорошо ли это? Нет. Такой подход абсолютно неинтуитивен.

Теперь второй. Придумываем отдельные теги для обозначения высоты и этажности на частях зданий.
Тогда на контуре здания можно будет совмещать теги для здания и теги для “базовой части” без всяких надстроек и пристроек. Если на
контуре не будет тегов для “части”, тогда объём здания рисуется на основе тегов высоты и этажности здания в целом, исключая те области,
где указаны building:part со своими параметрами.
Плюсы этого подхода:

1. Не нужно думать, что делать с совмещением двух объектов на одном контуре. Не нужно плодить мультиполигоны или изощряться,
   создавая полигон “здания без надстроек” (увы, бывает и такая порнография).
2. Сейчас невозможно отличить этажность здания, от этажности частей. При сборе статистики по зданиям это является сложностью - тег
   building:levels приходится рассматривать каждый раз в контексте прочих тегов (building:part, building:parts и т.д.). С вводом новых тегов эта
   проблема тоже исчезает.
   Главный минус - придётся всё это обсуждать, проводить через стадию пропозала, а потом пинать владельцев рендереров, чтобы те настроили новый приоритет тегов.

И ещё немного на тему высоты.
edward17 предложил для здания использовать теги building:levels и height, а для частей - building:part:levels и building:part:height.
Я же предлагаю для здания использовать building:levels и building:height, для частей - levels и height.
Объясню, почему так. Во-первых, это короче и проще запомнить.
Во-вторых, многие считают, что высота здания первична по отношению к высоте его частей, поэтому широко распространённый тег height
должен продолжать относиться к зданию. Но ведь это не так!
Высота “всего здания” на самом деле - крайне эфемерная и спорная вещь. Антенны, колпаки и плиты воздуховодов, дымовые трубы, шпили, кресты и статуи, съёмные ограждения крыш, самовольно надстроеннные мансарды-“курятники” и т.д. - учитываются ли они при подсчёте высоты? На эту темы ведутся вечные споры. Если кто-то решил позагорать и вынес на абсолютно ровную крышу кресло - увеличится ли высота здания на высоту этого кресла?
Очевидно, “высота всего здания” часто не может быть указана, либо является спорной. А вот высота его отдельных частей, прежде всего фасада, может быть установлена даже по спутниковому снимку. Именно эта высота нас чаще всего и интересует. Когда мы,
например, сравниваем дома на улице по высоте, мы сравниваем их по высоте фасада, а не по высоте антенн или плит воздуховодов,
которые обычно и вовсе не видны.
К тому же фасад - более долговечная вещь, чем разное вспомогательное хозяйство на крыше. Поэтому я предлагаю для указания высоты
частей здания, прежде всего частей, представлюящих собой те самые параллелепипеды, использовать тег height. Для указания высоты
крыши, как единой формы с определённым roof:shape, без учёта всяческих надстроек - roof:height. Для здания же в целом - building:height.
Соответственно, созвучно выбираются и теги для этажности - для здания сохраняется широко распространённый building:levels, для частей
вводится новый levels (не путать с level, тегом для указания расположения организации внутри здания).
Для указания минимального этажа и высоты используются min_level и min_height. Особо уточню, что в этом варианте min_level и min_height
не требуются на надстройках, более того, там они будут ошибкой. Только если под частью здания действительно ничего нет (лоджия,
подворотня), используются эти теги.

Откуда брать height, если недоступны чертежи здания? Лазерный дальномер есть далеко не у всех, да и с ним не так просто. А уж на глазок считать: “общая высота здания с учётом всех этих надстроек, на 2-3 метра больше, чем уровень крыши” - и вовсе тухляк.

Берёте здание, высота которого известна из надёжных источников. Соединяете в josm линией высшую точку здания с отбрасываемой ей тенью. Делите линию на n частей (например, метровых) n-1 точками, нажимаете “распределить точки”. Всё, линейка готова. Можно прикладывать к любому зданию в том же куске спутникового снимка и мерить. Естественно, будет погрешность. Но если подойти к подбору эталонных зданий с умом (брать не одно эталонное здание, а несколько, и повыше, и желательно стоящих на ровном месте, и чтобы тень не перекрывалась и была чёткой), погрешность можно сократить до дефекта склейки тайлов. То есть, плюс-минус метр. Если же здание типовое, можно ещё усреднить по нескольким и снизить погрешность вообще до полметра. С такой точностью и ширину-высоту нынче не везде рисуют.

levels и height - не очень понятно, к чему они относятся. А вот building_part:levels и building_part:height - понятно, к чему и для чего. А длинны не нужно бояться - есть же lanes:psv:forward и ничего страшного.
Кроме того, я уже писал, использование building_part вместо building:part не только логичнее, но и позволит отделить здания, нарисованне по старой схеме от зданий с новой схемой. Полезно это не только для рендеров, чтобы они знали, по каким правилам рисовать, но и для статистики.

А я считаю, что переименовывать теги, которые уже имеют широкое хождение - моветон, и ни к чему, кроме лишнего беспорядка, это не приведёт. Ситуация с power=substation и building=entrance тому примеры. Если есть желание указать, что тегирование происходит по новой схеме, надо использовать предназначенный для этого тег building:parts=(новая схема). А ещё лучше поменять все теги одномоментно, и вообще отказаться от необязательных костылей.

По поводу, какие именно теги использовать - можно провести голосование. Моя позиция такова: тег height должен быть сохранён для зданий в той или иной форме (для простых зданий - безусловно, для сложных - либо для зданий, либо для их частей), поскольку он универсален. Тег building:levels должен также сохранён в его нынешнем значении по тем же причинам. Остальное обсуждаемо.

Сейчас самое главное, что я хочу услышать - есть ли понимание у мапперов, плотно занимающихся 3d темой, необходимости перемен, или их всё устраивает? По какой схеме они тегируют сейчас здания с пристройками и надстройками? И были бы рады появлению возможности отмечать отдельно высоту и этажность здания и его частей, в том числе на одном объекте?

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

Было бы вообще замечательно, если бы все building:part разом поменять на building_part

Голосование - хорошая идея.
Согласен с тем, что building:levels - этажность только на зданиях.
По поводу высоты - на зданиях можно указывать height, на частях зданий - building_part:height. Это позволит не менять многие простые дома, где высота указана в height.

Лирика: Честно говоря, я никогда не рисовал лифтовые надстройки, и мне тоже вполне хватало старой схемы. Да и отказ от building:parts=horizontal меня тревожит. Не аукнется ли нам это, когда будем обсуждать поэтажные планы зданий в преддверии 20-летия OSM?

Не понимаю, зачем создавать разные теги для обозначения одного и того же - высоты или этажности (и чего угодно ещё). Это лишнее и никакая сферическая статистика такой подход не оправдывает.
Сейчас имеется возможность тегировать (для создания приблизительного объёма! а иной вряд ли возможен и вряд ли нужен в рамках OSM) любые пристройки/надстройки, ничего не изобретая. В этом плане меня (не столь плотно занимающегося, но всё-таки) вполне устраивает Simple 3D Buildings.
Не хватает в ней, на мой взгляд, чего-то вроде building:part=hole или building:part=void для отказа от мультиполигональной схемы. Странно, что такой элемент не ввели сразу.
Также нет возможности придать частям здания свойства, относящиеся к их функционалу (жильё, торговля, офисы и т.д.). Для этого можно было бы использовать building:part=apartments, building:part=retail, building:part=office и далее по аналогии с остальными тегами building=*.
Уже говорилось о проблеме стилобатов, когда под ними и на них размещены объекты инфраструктуры (дороги, парковки и т.д.). Здесь напрашивается вариант добавления к таким объектам layer (для плоского рендера) и level+какой-нибудь level:height (для объёмного).
Вот такие дополнения/изменения мне очень по душе.

Такое есть:

Simple 3D Buildings

Я посмотрел ещё раз картинку http://img-fotki.yandex.ru/get/6846/51351719.14/0_a54ec_2aada80e_orig и понял, что самая правая картинка неправильная. Потому что часть, у которой кол-во этажей отличается от максимального, имеет форму квадратного бублика, а потому должноюа рисоваться мультиполигоном. Кроме того, синий контур имеет максимальную этажность, поэтому его не нужно выделять как отдельную часть. Следовательно, единственно правильный вариант - картинка вторая слева.

Тегирую по традиционной схеме, но предпочёл бы не указывать этажность и высоту для основной части здания. В общем-то не против новой схемы, но однозначно нужен proposal. И еще было бы неплохо иметь тег указывающий количество технических этажей (или тогда уж учитывать все этажи а технические указать в этажном плане).

Действительно, не обратил внимания Только, почему-то, не указано ни одного примера из типов для наглядности.
Ещё там вот что есть

Как раз об устранении избыточности тегов.
А для полноценной замены мультиполигональной схемы достаточно добавить, кроме ролей part и outline, ещё hole для вырезания дырок в зданиях.
На этой картинке мне больше всего не нравится то, что самый простой и верный (с оговоркой: создать отношение и расставить роли) вариант назван ошибочным.
Что значит «этажность не всего здания, а части»? Это и есть часть здания с такой этажностью. Часть - потому что она вписана во внешний контур(outline). Внешний контур - такая же составляющая, как и все building:part, а всё вместе, собранное в отношение type=building - это здание. Вот на него, будь на то большое желание, можно было бы повесить пресловутую максимальную этажность, хотя смысла в этом не вижу.
Странную «старую схему» приводит автор картинки. Мультиполигоны мистические какие-то.
Там на внешнем контуре должно быть:
building=yes
building:levels=2
На внутреннем:
building:part=yes
building:levels=4
building:min_level=2 (помнится, говорилось где-то, что не обязательный)
Сегментированные мультиполигоны-контуры используются, когда в здании много сопряжённых (имеющих «общие» контуры в проекции сверху) частей разной высоты и/или формы. Вот тогда каждая деталь состоит не из цельного контура, а из составленного из отдельных сегментов («замкнутых» лишь в рамках отношения посредством очерёдности) мультиполигона. Эти сегменты одновременно участвуют в разных мультиполигональных контурах и могут иметь роли (и по несколько) inner и outer совместно.
«Дырочный» мультиполигон в таких случаях лепится из двух «контурных», где внутренний состоит из кусочков с ролью inner, а внешний из кусочков outer.
Во написал, прям как талмуд учебник))) Чегойто Felis Pimeja предательски молчит…

Это по какой схеме? Старой или новой? По новой схеме (максимальная этажность здания указана на контуре здания, отдельно обозначаются только части с меньшей этажностью) это здание правильно обозначено только на второй слева картинке. Первая слева конечно тоже правильная, но там на 1 объект больше.
А самая правая картинка - правильная только по старой схеме.

Уж запутался сам в схемах))) Справедливости ради (если по старой?), то надо их ещё в мультиполигон сложить (роли у всех - outer), но участники, разумеется, цельноконтурные, т.к. дробить их нет никакого смысла.
В общем - так же, как и «квадратный бублик», только внутри не inner и добавлены теги.

По ней мне не ясно, как из синего и зелёного контура получился синий, участвующий в мультиполигоне с role=inner. Автор многозначительно промолчал.

Она к старой схеме точно не имеет отношения, т.к. является новым предложением Danidin9

0_ef81f_ad980079_XXL.jpg1024×417 34.7 KB