Тегирую по традиционной схеме, но предпочёл бы не указывать этажность и высоту для основной части здания. В общем-то не против новой схемы, но однозначно нужен 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
Самопересекающийся контур зло большее, чем мультиполигон.
Согласен, что как-то не очень, а в чём зло?
Без всяких выкрутасов вместо этого должно быть как в примере с пустотой, но:
синий контур имеет дополнительно building:levels=4 и role=part
Из новшеств, предлагаемых мной, получаются:
- Отказ от принципа «максимальная этажность на внешнем контуре», что снимает необходимость что-либо выдумывать;
- Добавление role=hole в relation type=building, что делает необязательным построение мультиполигонов для пустот в геометрии зданий.
Мне видится до глупого просто и безболезненно. А ещё building:part=[тип здания по аналогии с building=]* активнее применять и кого-нибудь попросить насчёт рендера
, чтобы такие куски не сливались в одноцветный полигон.
Забудьте про type=building. Его никто не будет поддерживать хотя бы потому, что возникает новая проблема с адресацией.
На объекте, где тег building, должна стоять этажность всего здания. В данном случае этот объект - полигон внешнего контура. Если там будет стоять этажность=2, то будет ошибочно посчитатно, что это здание 2-этажное, хотя на деле оно 4-этажное. Если и кто-то будет собирать статистику по этажности зданий, он получит неверные данные.
Поэтому приходится делать три объекта - один для здания и два для частей. Поскольку надо как-то уместить три объекта на двух линиях, мультиполигоны неизбежны.
Для понимания, почему building:levels=2 в моём примере является кольцевым мультиполигоном, представьте такую ситуацию. В степи болото. Болото покрыто лесом, кроме его центральной части, где “чистое” болото без растительности.
Как это тегировать? Рисуется два контура по внешней и внутренней границам леса. Соответственно, лес изображается мультиполигоном, с outer на внешнем контуре и inner на внутреннем. Тег болота ставится на внешний контур, потому что вся область внутри заболочена.
Так и у нас, только вместо болота - здание, а вместо леса - его двухэтажная часть. Внутри внутреннего контура - “чистое” здание, так сказать, в его четырёхэтажной форме. Поэтому эта область и вырезается из двухэтажной части.
Читайте про мультиполигоны, что я могу сказать. В josm, кстати, если попытаться объединить синий и зелёный контуры с рисунка, мультиполигон создаётся автоматически.
Вы предлагаете отказ не от этого принципа, а от принципа “вместе с тегом building должна стоять этажность всего здания”. Далее см. выше.
Вы по сути предлагаете поддерживать новое отношение type=building вместо отношения type=multipolygon. Проще здесь ничего не становится.
Зато те кто не видит этого отношение отрисует сплошное здание, хотя могли бы показать дырку.
В каком месте? Адрес как висел на полигоне building=* так там и остался. А отношение нужно лишь для 3D рендера остальные его с лёгкостью игнорируют.
В общем я понял, вся тема свелась к “я не умею мультиполигоны” и начинаются велосипеды, которые выглядят для тех кто осилил их глупостью.
Хм, я всегда думал, что если для здания есть особое отношение, то адрес, как важнейший атрибут здания, должен на отношении и стоять. Я действительно никогда не использовал type=building, т.к. однажды прочёл описание в вики, и понял, что использовать его излишне. В это отношение пытаются запихнуть всё, что только можно, и нельзя - и части здания, и крышу, и входы, и poi. А про то, что адрес должен быть на контуре - там ничего такого не говорится, это уже сами мапперы придумали потом для простоты и удобства. Цитирую вики: “Почтовый адрес: Это непростая тема…” Дальше идёт ссылка на схему карлсруэ с удалённым уже описанием и куча рекомендаций без какой-либо конкретики. И в итоге (снова цитата оттуда же):“Очень важно с умом решить имеют ли смысл данные рекомендации. Вы одни знаете обстановку на месте. Имеет смысл комбинировать рекомендации или найти новую схему.”
Так вот, я нарисовал не одну тысячу building:part, но никогда не испытывал надобности вводить какое-то новое отношение для здания. Мне не понятно, зачем нужно отношение, не привносящее ничего нового. Уберите его - и ничего не изменится. Рендеры, что есть, умеют определять принадлежность building:part к тому или иному зданию по геометрии.
В России его почти никто не использует.
Сейчас идёт речь совсем о другом. О тегировании building:part. Если ли type=building, нет ли - building:part никуда не денутся. А там есть куча неоговоренных нюансов, которые каждый маппер понимает по своему.
Он вообще не несёт тегов, а только распределяет роли. И да для адреса есть отдельная роль, если адрес не на здании, а в виде точки.
Речь вёл не про отношение type=building, а про мультиполигоны для building:part.
Было бы здорово попинать Мапник насчёт этого, так как он является самым распространённым 2D-рендером. Чтобы например такие здания рисовались хорошо.
Давайте напишем сюда все моменты тегирования building:part, которые не понятны, обсудим и внесём в вики.
По поводу адресации - адрес всегда ставиться на внешний контур здания, на котором стоит тег building. Если украинская схема адресации, то потом этот контур включается в отношение associatedStreet.
Тупой вопрос - а тема зданий переменной этажности это чисто проблема русскоязычного сегмента или что-то обще-ОСМовское? То есть если мы внтури себя найдём какое-то решение, оно будет обязательным для остального ОСМ?
(*грустная улыбка) Если всё-таки удастся, тогда будет иметь смысл продвижение идей в международное русло.
Именно. Только не хватает до полного набора одной роли. Не будь необходимости «вырезать дырки» - отношение building в принципе было бы не нужно. Речь (с моей стороны) об альтернативе мультиполигонам идёт в разрезе упрощения. В этом и есть задумка Simple3D. Гораздо проще накидать пересекающихся/накладывающихся контуров с заданными свойствами, а потом объединить в отношение с заданными ролями, нежели из лоскутов сшивать каждый отдельный контур в мультиполигон.
с 38-й попытки я вытянул из вас то, что хотел узнать Вы бы по-человечески сказали, что в результате создаёте мультиполигон из двух контуров (только весьма затейливым способом), на который ставите теги building:part и др., а поверх идёт контур-полигон building=yes. Или не так?
Правда о такой схеме мне ничего не известно, когда мультиполигон размещается внутри полигона.
Думаю, те, кто будет рисовать 3D-здания, умеют работать с мультиполигонами.
Моё мнение, что лучше уж не делать новую роль для отношения, а вместо этого придумать новый тег building:part.
О такой схеме чего? По-моему, нормальная ситуация.
Меня, в целом, устраивает текущая схема, а для новой предложений нет. Но я с интересом слежу за обсуждением
type=building сродни role:subarea в отношениях границ и role:tributary (это про притоки, оно вообще не документировано) в отношениях рек. Это некоторая избыточность, которая позволяет здорово упорядочить данные. Кроме того type=building необходим если вам попадётся экзотический пример соседних зданий с пересекающимися проекциями на плоскость (лениво сейчас рисовать иллюстрацию но если приспичит, могу изобразить).
А это вообще не аргумент. В России от силы десяток человек регулярно рисуют 3Д. Я использую type=building. Так что по грубым прикидкам 10% целевых ру-маперов, таки используют этот релейшен
Кстати, касатедьно вашего примера двумя страницами ранее, пресловутые 339 type=building вместе собирают чуть менее 5000 building:part (я не поленился проверить). Так что процент не так уж и мал. Даже больше чем моя грубая прикидка
А вот с этого места, пожалуйста подробнее. О каких неоговоренных нюансах идёт речь? Технические этажи и стилобаты?
+1. Справедливости ради, проблема скорее лежит в области инструментария. Как это не печально.
Нет, конечно. Сейчас Ру-сообщество пытается изобрести велосипед. Это нормально. Если он окажется быстрым и комфортным, то можно написать пропозал и толкнуть в мир. Так как рисовальщиков 3Д пока не так много, то новая схема имеет все шансы неплохо прижиться, буде она действительно прорывной.
А теперь, моё мнение касательно текущей схемы более развёрнуто.
Она ни разу не идеальна. Более того, местами она чудовищно ужасна (один из столпов - building:min_levels является, по сути жутким костылём). И связано это в первую очередь с попыткой впихнуть 3Д в 2Д. Но ёжики кололись…
С другой стороны, не смотря на бурные обсуждения, ничего лучше придумано не было. Чтобы лучше понимать почему пришли к тому, к чему пришли, советую почитать обсуждение на странице Simple 3D Buildings (Ахтунг - Инглиш!!!). Эта простыня проливает свет на многие неочевидные моменты.
- Мелкие надстройки в рамках текущей схемы всё ещё вполне возможны (под ними мы в итоге и схоронимся - ситуация с тегированием формы крыш весьма показательна)
- Мелкие доработки, меняющие принципы работы отдельных узлов схемы не пройдут, т.к. потеря обратной совместимости, а нарисовано уже не мало.
- В радикально новую волшебную схему в рамках текущих технологий я не очень верю (но мало ли ;)).
Поэтому нормальной схемы 3Д мы не получим пока:
- В базе не появится честная 3-я координата (а это вовсе не ближайшая перспектива: “Пока в 2Д всё хорошо не отрисуете, мы вам третье измерение не дадим” ;)).
Вот тут я полностью согласен с Ильёй - геометрию надо отвязывать от семантики.
Вот тогда можно будет не заниматься извращениями, а двигаться в сторону BIM (а возможно и более комплексных концепций)
P.S. Сорри за простыню
Он незаменим когда мапятся изгибы крыш http://wiki.openstreetmap.org/wiki/File:Roof_diagram.jpg. Думаю спорить не будете, что тут без бутылки отношения не разберёшься.
А так вообще зреет идея простенького 3Д-редактора типа выдавливания.
мне кажется что надо вносить пропозал на внешнюю внедряемую 3Д-модель, и в той модельке все 3Д-заморочки развивать.
так же как, к примеру, F4 отображает собор парижской богоматери с всеми хитрыми конструктивами готической архитектуры плюс наложенными текстурами поверхности.
Просили конкретные вопросы - пожалуйста. Вот, по пунктам:
- метод подсчёта этажности здания. Что и когда учитывается:
1а) цокольные этажи и полуподвалы
1б) техэтажи в промежутке между жилыми
1в) чердаки
1г) нежилые надстройки
1д) мансарды (жилые этажи под наклонной крышей) - метод подсчёта высоты здания. Что и когда учитывается:
2а) неплоские крыши
2б) капитальное ограждение крыши (видимые как продолжение стен)
2в) съёмное ограждение крыши (металлические оградки)
2г) капитальные технические надстройки - лифтовые блоки, выходы вентиляции, резервуары с водой и т.п.
2д) декоративные фальшстены и башенки и т.п.
2е) антенны, дымовые трубы и колпаки воздуховодов
2ж) шпили
2з) статуи, кресты и т.п. - расчёт высоты и этажности зданий, стоящих на склоне местности
3а) при разбиении на секции со сдвигом по высоте
3б) без разбиения на секции (цокольный этаж/этажи уходят под землю) - как обозначать стилобаты
4а) подземные
4б) надземные без жилых и общественных помещений
4в) с жилыми и общественными помещениями, имеющие отдельный адрес
4г) с жилыми и общественными помещениями, имеющие тот же адрес, что и у здания - тегирование назначения частей здания
5а) building:part=*(отличное от yes) или building:part:use?
5б) тег building:Plan - использовать ли, и как сделать более универсальным
5в) допустимость вложенных в здание building:part - помещений, относящихся к какой-либо организации, как это связать с внутренним планом здания (indoor mapping) и как избежать деформации прорисовки остального здания (например, добавить на него тег building:part=yes (или какое-то другое значение) (см. также пункт 8а)) - допустимо ли не указывать часть, равную по высоте и этажности зданию?
- необходимость частей-мультиполигонов с единственным outer на контуре здания у зданий, разделённых на части по горизонтали, где одна из частей (обычно - нижняя) повторяет форму здания (это даже не вопрос, это надо просто донести до мапперов, ибо многие просто не понимают такой схемы)
7а) допустимость использования такого метода для горизонтальной раскраски здания и/или разметки этажей по назначению.
7б) следует ли делать так для зданий с незначительными надстройками, или их можно игнорировать при подсчёте общей этажности, и что более важно, высоты (см. пункт 2г) - надо ли указывать building: min_level и min_height для частей здания, под которыми есть другие части (но нет проёмов в здании)
8а) проблема с building: min_level у надстроек (если для надстроек указывать building: min_level, а у основной части здания нет тега building:part, то программа ошибочно воспримет тег building: min_level на надстройке, и “вырежет” массив здания под ней до земли, будто там подворотня.) Следует ли использовать в таком случае building:part=yes (или какое-то другое значение) на здании? (Связано с пунктами 2г и 7б) - тег building:parts - рекомендовать использовать или нет?
- отношение type=building для каждого здания с хотя бы одной building:part - рекомендовать использовать или нет?
Также связанные вопросы и проблемы:
10) здания, построенные в разное время, из разного материала, по разным проектам, но имеющие один адрес - тегировать как части одного здания или как отдельные здания?
11) нужен набор рекомендуемых, наиболее распространённых цветов для фасадов и крыш
12) какие использовать теги для материала наружных стен и материала здания. (Подробнее - http://forum.openstreetmap.org/viewtopic.php?pid=441496#p441496 )
Спасибо за всё так детально перечисленное. На связанных вопросах и проблемах нумерация сбилась.
1 и 2 - на мой взгляд, самые сложные, тут надо думать.
1б. UPD_6: Это как? Но если они по высоте равны или примерно равны жилым/коммерческим этажам, то их тоже нужно считать.
1д. UPD_6: Да, мансарды нужно считать.
2. UPD_7: Я вот как думаю: для чего нужно указывать высоту здания? Чтобы человек на местности мог сориентироваться. Я считаю, что человек при определении высоты будет смотреть на линию крыши, а не на декоративные надстройки/стены/скульптуры и тем более не на антенны/шпили, потому что они могут быть просто не видны. Также при расчёте высоты нужно учитывать капитальность надстройки и площадь, которую она занимает на крыше. Поэтому я считаю, что 2в, 2д, 2е, 2ж, 2з не нужно учитывать при расчёте высоты здания. Также, так как с земли весьма проблематично определить, где заканчивается здание и начинается капитальное ограждение крыши, то считаю, что 2б нужно учитывать при расчёте высоты здания.
2а. Если крыша неплоская, то высоту считаем по верхнему коньку крыши.
3. Единственное, что могу сказать: пока у нас 2D карта, о разбиении можно не говорить. Да и вообще разрезание здания по вертикали - глупость, потому что здания часто стоят на равномерных (ну или почти) склонах.
**4а.**building:levels:underground и то, что я написал ниже по пункту 4.
**4б.Разве это стилобат, если сверху на нём нет других зданий?
4в. Если у стилобата отдельный адрес - то это отдельное здание, на него building=, адрес и никаких building:part.
UPD_3: На контур здания, которое на стилобате, -building=, адрес и **layer=**кол-во этажей стилобата. Вместо layer можно использовать **building:min_level=**кол-во этажей стилобата, **building:levels=**кол-во этажей стилобата + кол-во этажей самого дома.
4г. UPD_5: На контур стилобата - building=yes, **building:levels=**кол-во этажей стилобата + кол-во этажей самого дома, building:part=yes, **building:part:levels=**кол-во этажей стилобата. Здесь как раз разрезание по горизонтали, о котором я писал в 7.
5а. Мой ответ LLlypuk82.
5б. Если обозначать отдельные помещения как building:part, то в building:levels_plan нет необходимости.
5в. Мне такая идея нравится. Можно, например, обозначить дом, первые 2 этажа которого - поликлиника.
7. Необходима или часть-мультиполигон, или часть-линия, состоящая из тех же точек, что и контур.
UPD_1: От этих элементов можно избавиться, если для высоты части здания использовать отдельный тег, как я ответил на последнюю цитату тут
UPD_4: Это нужно, только если здание разрезается по горизонтали (по этажам например).
9. Если рендереры могут отрисовать здание без этого тега, то он лишний.
10. Для обычного здания он не нужен, но
11 (который ошибочно 10). Если у здания один адрес, то это одно здание с несколькими частями.
UPD_2: Ещё заметил такую вещь на странице Simple 3D buildings:
Что это такое? Как это вообще так, что на контур здания с одинаковой этажностью вешается building:part?
Обнаружил одну о-очень большую странность в f4map, которая ставит под сомнение всё, что написано выше про “части с этажностью по умолчанию” (пункт 6 из моего последнего поста)
Итак, если на контуре здания нет тега building:parts, то да, части здания, которую не перекрывает ни одна building:part, присваивается этажность с конутра здания. Но стоит только проставить building:parts на контур здания (неважно с каким значением), то с этой “дефолтной части” этажность исчезает!
Вывода можно сделать два:
- f4map всё же как-то учитывает тег building:parts
- отмечать надо все части. building:parts=simplified_scheme , которую я пытался протолкнуть, пока в f4map явно не реализуема.
И кстати, кто-нибудь знает, как можно связаться с разработчиками этого рендера, чтобы хотя бы объяснить ситуацию. Я пытался через их сайт, но там только чтобы задать вопрос требуется какая-то регистрация, и я так и не разобрался, где и зачем.