Тупой вопрос - а тема зданий переменной этажности это чисто проблема русскоязычного сегмента или что-то обще-ОСМовское? То есть если мы внтури себя найдём какое-то решение, оно будет обязательным для остального ОСМ?
(*грустная улыбка) Если всё-таки удастся, тогда будет иметь смысл продвижение идей в международное русло.
Именно. Только не хватает до полного набора одной роли. Не будь необходимости «вырезать дырки» - отношение 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 явно не реализуема.
И кстати, кто-нибудь знает, как можно связаться с разработчиками этого рендера, чтобы хотя бы объяснить ситуацию. Я пытался через их сайт, но там только чтобы задать вопрос требуется какая-то регистрация, и я так и не разобрался, где и зачем.
Или я не так понял, или вас контачит по партсам. Когда размечаются куски здания никакой контур здания с building=yes не должен браться в расчёт.
Теперь я не понял, что Вы имеете в виду) Ситуация такая: у двухэтажного детсада в виде буквы Н перемычка одноэтажная. Раньше я отметил её как building:part=yes building:levels=1, а на здании были теги building=yes building:levels=2. Всё, больше никаких building:part и тегов не было, и f4map рисовал всё как надо. Но недавно я решил добавить тег building:parts=(какое-то значение) на контур здания, чтобы всем было видно, что у здания есть части с иной этажностью. И - вуаля - сразу после этого f4map перестал отображать этажность на двухэтажных крыльях здания, осталась видна только перемычка.
Ну так неправильно же. Их нужно было добавлять на отдельные объекты-палочки буквы. А так у вас пересечение частей.
А разве наличие внутри основного контура building:part=yes не говорит о частях с отличающейся этажностью? 
building:parts может иметь значения vertical/horizontal/mixed. Какое из этих значений стоит на контуре здания?
Если это опечатка, и на контуре здания стоит building:part, то это неправильное обозначение.
Поясню ещё. До недавнего момента я так и обозначал здания - по building:part на каждую часть. Так, для данного детсада делал три building:part - на перемычку и на оба корпуса - “ножки”. Но в определённый момент заметил, что отмечать одну перемычку достаточно, чтобы f4map корректно рисовал всё здание. После этого я предложил в этой теме упрощённую схему разметки зданий, когда рисуются только те building:part, этажность (и высота) которых отличается от этажности (и высоты) здания в целом, отмеченных на контуре здания.
Есть множество случаев, когда это было бы оправдано и позволяло избегать множественных наложений линий и/или использования мультиполигонов.
Я сделал несколько тестовых зданий, и удостоверился, что схема работает.
Однако потом пришла мысль, что надо как-то отметить эти тестовые здания, чтобы их не путали со зданиями, размеченными по схемам vertical/horizontal/mixed. Я придумал ключ simplified_scheme к тегу building:parts и навесил его на все building, размеченные по упрощённой схеме. И после того, как я это сделал, f4map перестал рендерить “ножки” детсада и все дефолтные части зданий в аналогичных случаях.
По поводу пересечения частей - не понимаю, о чём Вы. Никакого пересечения здесь и подавно нет. Одно здание плюс одна часть. И кстати, почему пересечение building:part - ошибка? Схема building:parts=horizontal и построена на том, что разные building:part накладываются друг на друга, и ничего, работает.
Написал выше - тег ввёл по аналогии с вики, чтобы отличать здания, замапленные по новой, упрощённой схеме. К тому же, введение этого тега может быть оправдано само по себе. Например, если кто-то качает из базы только здания, но не building:part, наличие этого тега на контуре позволяет ему понять, что здание разноэтажное.
На контуре стояло building:parts=simplified_scheme. Но ситуация повторяется и любыми другими ключами building:parts, проверено.
Нет, это не опечатка, там стоит building:parts.
Это называется “разметка под рендер”, хотя и отличается от обычного случая попыткой ее “легализовать”.
Как я понял, нужно попросить разработчиков F4map, чтобы они сделали, чтобы здания с building:parts=simplified_sheme рисовались так, как сейчас рисуется здание без building:parts. И всё будет хорошо.
А будет ли корректной отрисовка зданий переменной этажности мультиполигонами рилейшн тулбоксом? Что бы не накладывать полигоны друг на друга, а использовать одни и те же линии и для общего контура и для всех building:part
Я бы даже сказал, так эстетически правильно.
но дидактически как минимум спорно.