Да, “останавливаться на достигнутом” - это не всегда хорошо, но есть ли реальная возможность усовершенствовать схему так, чтобы не случилось ситуации конкурирующих стандартов и чтобы масштаб внедрения новой был сравним с Simple 3D? Это вызывает сомнения.
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings - предложение никогда и не принимали до конца
Более полезное описание http://wiki.openstreetmap.org/wiki/Tag:type%3Dbuilding
type=building так и не приняли, а вот мультиполигоны все поддерживают.
Как я понимал type=building только лишь усложняет мультиполигоны введением явных outline part ridge edge. Это упрощает поиск данных в отношении но не является определяющим критерием как указывать информацию.
Т.е. у нас есть здание с разноэтажными частями, мы его можем затегировать через мультиполигон без потери информации, мы его можем смоделировать и затегировать через отношение type=building без потери информации.
Основная проблема что не описаны все детали (детальное сравнение правил схем) и поддержка в программах того или иного способа.
Совсем не так.
Допустим, у нас есть здание с разноэтажными частями. Его контур (building=) и его части (все или только те, чья высота отличается от максимальной высоты здания, - неважно) (building:part=) мы можем обозначить только полигонами. В роли полигонов могут выступать замкнутые линии или отношения type=multipolygon.
Можно пойти одним из трёх путей:
- Использовать для всего здания и его частей только замкнутые линии;
- Использовать для всего здания и его частей только мультиполигоны;
- Использовать для чего-то замкнутые линии, а для чего-то - мультиполигоны
Что из этого выбрать - зависит от стиля маппинга каждого конкретного маппера и его предпочтений. Главное - все эти пути верны и дают одинаковый результат.
Однако иногда мы не сможем обойтись без использования хотя бы одного мультиполигона (например, когда здание имеет форму бублика с двориком внутри). Хотел бы ещё раз обратить внимание: даже если мы обозначим дворик с помощью мультиполигона, всё равно не имеет никакого значения, какую технологию (замкнутые линии или отношения-мультиполионы) мы используем для других частей здания.
Обозначив все части здания замкнутыми линиями или мультиполигонами, мы уже можем увидеть результат в одном из рендереров / на одном из сайтов, поддерживающих 3D.
Всё, что делает отношение type=building - собирает в кучу контур здания (building=), все его части (building:part=), коньки и края крыши. Имея перед собой список всех “деталей” здания, легче находить нужные и редактировать их. Здесь можно провести аналогию с отношением type=site - оба эти отношения просто собирают вместе компоненты какой-то одной сущности.
По сути, отношение type=building - ни в коем случае не альтернативная схема обозначения объёмных зданий. Оно существует отдельно от схем и может применяться с любой из них, никак не используется для рендеринга (насколько я знаю), противоречит принципу Relations are not Categories.
Возможно, отношение type=building как-то используется для Indoor Mapping-а. Возможно, использование отношения type=building обязательно при рисовании крыш. Возможно, использование отношения type=building обязательно при рисовании домов, где один дом частично “залазит” на другой. Я говорю “возможно”, потому что никогда с таким не сталкивался и точно не знаю.
Совместимость для обоих подходов одинаковая. Работают оба (даже в их смеси 50/50). И в 3-d и в 2-d.
type=building по сути является частным случаем type=multipolygon, в котором упрощается построение геометрии до обычных (цельных) взаимонакладывающихся и вложенных многоугольников-полигонов, а также исключается туча мультиполигонов, формирующих эти многоугольники. А поскольку один из них (внешний контур) — полигон с тегом building=yes, то проблем совместимости никаких не возникает. И всё работает даже без создания отношения type=building.
2-d рендереры не видят buildung:part=yes, но понимают мультиполигоны с building=yes (как и другие площадные теги).
Мультиполигоны (type=multipolygon) изначально предусматривают role=inner для составных частей и «вырезают» на их месте либо пробел, либо участок с индивидуальными свойствами.
А type=building не предусматривает аналогии role=inner и проигрывает в функционале из-за этого. О заполнении этого пробела (в виде role=void) и ведётся разговор.
Почему понадобилось «городить» какой-то «частный случай» для зданий? Потому что именно они (если рассматривать их как мультиполигоны) обладают высокой концентрацией разносвойственных фрагментов в пределах весьма компактной площади (в отличие от подавляющего большинства других случаев: землепользование, природные ландшафты и т. п.)
При этом, эти фрагменты являются частями одного объекта (здания), в отличие от разных, но смежных земель или ландшафтов. Это приводит к чрезмерной напичканности одного «несчастного» здания отношениями type=multipolygon и — в свою очередь — к весомому усложнению как внесения данных, так и — особенно — их редактирования. А, между прочим, этап внесения не многим отличается от последующего редактирования.
Вывод: необходим upgrade Simple 3D Buildings, не более.
Объективно говорить можно не о стилизации mapping-а bilding-ов, а о вынужденном применении type=multipolygon-отношений в совершенно конкретных случаях.
edward17, вы по каким соображениям комбинируете подходы, а не выбираете один из них (который самодостаточен, например)?
Нет, совсем не так.
Отношение type=multipolygon предназначено для создания полигона (замкнутой области), то есть геометрии с тегами. Если его участниками будут незамкнутые линии, то программы (например, osm2pgsql, osm2mp) смогут преобразовать их полигон.
Отношение type=building предназначено для хранения всех частей здания в одном месте, об этом писал в своём предыдущем посте. Если его участниками будут незамкнутые линии, то программы… не сделают ничего, это будет ошибкой. Отношение type=building - просто список.
Участниками отношения type=building могут быть отношения-мультиполигоны, а вот участниками мультиполигона другие мультиполигоны быть не могут.
type=building - вовсе не частный случай type=multipolygon.
О комбинации каких подходов идёт речь? Об использовании замкнутых линий и отношений-мультиполигонов в пределах одного здания?
Если да, то я посмотрел на домики, которые рисовал в 3D и могу сказать, что почти никогда не комбинирую эти два подхода. Я лишь утверждаю, что так можно делать, и это будет правильно отражать реальность и правильно работать (т. е. рендериться).
Использую комбинацию в двух случаях:
- Там, где не обойтись без мультиполигона (например, школы с внутренним двориком)
- При горизонтальном разрезании здания на части (на “слои”, а не на “столбики”; соответствует тегу building:parts=horizontal), когда контур здания полностью совпадает с одной из его частей. Считаю, что лучше этот контур обвести линией без тегов и сделать два мультиполигона с одним участником - этой линией с ролью “outer”, чем рисовать две накладывающихся линии (пример: контур, часть), или делать так: контур, часть. Эти здания я обязательно исправлю.
Вот это и плохо. Исправляется предложенной поправкой. В итоге — одно простое отношение с описанием геометрии в том числе.
А не проще — объединить теги с накладывающихся контуров на одном из них, а второй удалить? Ну а там, где вы использовали type=multipolygon (без тегов геометрии) странным образом (участником является замкнутый контур с тегами геометрии) — удалить отношение, а его теги (адреску и проч.) перенести на этот же контур.
На мой взгляд, вы одно изощрение хотите заменить на другое: сначала беспричинно плодите одинаковые совпадающие контуры (отдельно раскидывая по ним теги), а потом — удаляете лишние контуры, но при этом плодите странные мультиполигоны (или заменяете один странный мультиполигон на два ещё более странных)…
Ещё такие соображения:
Если что-то работает, то важно определить:
- Благодаря или вопреки;
- Простое или сложное (а если не видно разницы — зачем усложнять?)
Не получится.
На контуре здания должно стоять, например building:levels=5, а на одной из его частей - building:part= + building:levels=2*. Геометрия у двух этих объектов одинаковая. Если все теги с них обоих перенести на один полигон, то что нужно будет писать в теге building:levels=*? 2 или 5?
И даже если мы предположим, что отказались от указания максимальной высоты здания на его контуре, то то тогда на "объединённом полигоне будут теги building= + building:part= + building:levels=2**. Вопрос: как понять, к чему относится тег building:levels=* - к зданию или к его части?
И даже если мы предположим, что для частей здания вместо building:levels=* используется building:part:levels=* (кажется, такое предлагалось в этой теме), то всё равно здание и его часть - разные сущности, поэтому в базе данных они тоже должны быть представлены двумя разными объектами.
Поэтому два мультиполигона - единственный красивый вариант в этом случае.
P. S. С тегом height=* те же проблемы.
Стоп, если геометрия одинаковая (проекции совпадают), то как у этих частей могут отличаться building:levels?
Не понял насчёт «к чему относится»: роль «здание» играет внешний контур, у него своя этажность (а не максимальная); у остальных частей — другая этажность.
Совпадать проекции могут, если здание хитрой конфигурации, например:
Но тогда у верхней части буде ещё building:min_level указан.
А о каких случаях вы говорите — не понимаю.
building отличается от building:part ровно ничем (для 3-d рендеринга).
building нужен для 2-d, для наглядности (знать: это — здание, а это — его части), туда же прикручивают адресную информацию.
Но, имея отношение type=building, даже это (наличие контура building) не обязательно (потому что уже есть части, объединённые в отношение), а требуется только для совместимости.
Кстати, с какого-то времени было принято, чтобы различные атрибуты прописывались именно на отношении type=multipolygon. Вполне логично то же самое распространить на type=building (Но это вовсе не обязательно! Слышал о желании всё на relation «перегнать» — вот и пожалуйста, на перспективу).
Я говорю о случаях, когда здание разрезается на части по горизонтали.
Вспомнил, какой пример могу привести:
http://www.openstreetmap.org/relation/3460642 - здание
http://www.openstreetmap.org/relation/3460645 - первый этаж, контур которого совпадает с контуром здания
Вот как это выглядит на F4Map:
Это место: http://demo.f4map.com/#lat=48.0382702&lon=37.7823773&zoom=21&camera.theta=62.189&camera.phi=-35.237
Хороший пример, на мультиполигонах. Я вот чего не понимаю: зачем вы создавали 2 мульти, отличающихся только тем, что один атрибутирован как building:part (этажность указана), а другой — building (без этажей, но с адресом)?
И получается, что у вашего здания «нет этажей». Уважаемый freeExec не получит желаемой статистики 
Так или нет?
Но не это — главное. Важнее то, что дублёр в виде building:part — не нужен, а его теги нужны для building.
Один мультиполигон - здание, другой - часть здания. Два разных физических объекта, в базе им соответствуют тоже два разных объекта (здесь - мультиполигона).
В данном случае - так. Моя ошибка. Это было моё первое 3D здание в OSM, тогда я ещё не знал всех правил. Но на этом мультиполигоне должен быть тег building:levels=4.
И, если говорить вообще правильно, то оттуда нужно убрать тег building:parts:horizontal=yes. Он там стоит по той же причине - не знал точно, какой тег использовать - building:parts=horizontal или building:parts:horizontal=yes, поэтому поставил оба 
Физический объект-то один, абстракции, его отражающие — разные. Но только до тех пор, пока мы требуем выполнения «принципа максимальной этажности». Строго говоря, получается лишняя (пустая, ничего не несущая) абстракция в угоду указанному принципу.
Гораздо логичнее (и лаконичнее) иметь связки «часть физического объекта - абстракция, его отражающая».
Кстати, у вас такие же огрехи (этажность для building) и в других примерах.
Народу (читающему ветку) или очень весело, или очень грустно, или очень пофигу 
Ну, мне стало просто скучно, потому что вся моя аргументация осталась проигнорирована и обсуждение опять свелось к техническому вопросу, который лишен практического смысла.
Поддерживаю. Мне тоже скучно. К сказанному уважаемыми edward17 и BushmanK добавить нечего. LLlypuk82, вы пытаетесь компенсировать неудобство существующих редакторов жертвуя логичной законченностью текущей схемы тегирования. Да, я внимательно читал все ваши рассуждения.
Тогда всё — я сдулся, добавить больше нечего. Конечно, эффективнее было бы обращаться напрямую к ребятам F4map, например, но общение на неродном языке при недостаточном владении отталкивает.
P. S. Мне было интересно, во всяком случае (ну, хотя бы, ошибки обнаружились в процессе обсуждения )
P. P. S. Создателю »сего« (и иже с ним) наивно говорить о сложности и упрощении. Но надо понимать, что подобные случаи исключительны (немножко другие цели, а — главное — иные средства, сомневаюсь, что это делалось вручную на глазок).
Что-то я никак не могу понять, что не так делаю. попытался отрисовать главный корпус МЭИ. Вроде как заполнил весь полигон здания его частями. в kendzi3d показывает как я хочу, на f4map какой-то ад.
Гляньте, кому не лень, ткните в ошибку.