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 (для объёмного).
Вот такие дополнения/изменения мне очень по душе.
Такое есть:
Я посмотрел ещё раз картинку 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
Самопересекающийся контур зло большее, чем мультиполигон.
Согласен, что как-то не очень, а в чём зло?
Без всяких выкрутасов вместо этого должно быть как в примере с пустотой, но:
синий контур имеет дополнительно 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.
О такой схеме чего? По-моему, нормальная ситуация.