К счастью виртуальные слои работать не будут. Слишком сложно реализовать, слишком сложно маппить, слишком сложео протолкнуть. Сторонний сервис это даже не смешно. Откуда возьмется инфраструктура? Сервера? Редакторы? Кто будет поддерживать связь? Как привлечь людей маппить 3D там, а не в OSM? Что делать с building:levels/building:height?
Раз уж никто не может сказать, что конкретно обозначает building=yes (или что считать зданием), может считать что building=yes это часть здания фиксированной высоты. Ничуть не хуже фундамента или проекции. Если кому-то нужны плоские здания, прекрасно, пусть строит проекцию (объединяет полигоны по union) или выбирает полигоны, которые покоятся на земле, в зависимости от потребностей.
Я за building:height, building:min_height + отношение building. Недостатки те же, что и так есть. Несовпадение элемента адресации с полигоном building=yes есть и сейчас. В любом случае эту проблему придется решать. Отсутствие поддержки в редакторах. При любой схеме ее не будет до тех пор пока не сделают.
Зато плюсы у такой схемы огромные:
Она позволяет маппить подавляющее большинство зданий
Она совместима с тем, что замаплено уже сейчас
Она достаточно проста
Позволяет ровно ту точность, которую может дать сообщество любителей
Пока резюмирую то, что обсудилось в IRC. Позже можно сделать пропозал.
Одно здание должно быть одним объектом. Очевидно, что в нетривиальных случаях, как-то здание состоящее из частей разной высоты, этим объектом один полигон быть уже не может и надо использовать отношение.
Существующие отношения не подходят. В частности, самое очевидное (мультиполигон) потому что
а) Не позволяет использовать касающиеся внешние контуры.
б) Тем более, не позволяет использовать пересекающиеся внешние контуры.
в) Не позволяет задавать тэги на частях
г) (что следует из в) - никак определяет что делать когда тэг проставлен и на контуре и на отношении.
Нелюбителям 3D напомню, что и безотносительно 3D возможности вменяемо обозначить здание с магазином сейчас нет.
Поэтому есть идея ввести новое отношение, я предложил type=physical. Членами, как и в мультиполигоне, выступают полигоны с ролями inner и outer, при этом допускается касание и пересечение контуров, а также тэги на членах отношения, которые задают свойства отдельных частей объекта и имеют приоритет над тэгами отношения.
Простейший пример:
way 1: building:levels=2
way 2: building:levels=10
relation: type=physical + building=yes + building:levels=10 + addr:street=* + addr:housenumber=*
Профит:
Одно здание - ровно один объект, причём полностью описанный тэгами на отношении
Добавление поддержки в существующий софт скорее всего тривиально, ибо объект можно обрабатывать как мультиполигон - объединением outer контуров и вырезанием из суммы inner’ов
При этом можно однозначно определить конфигурацию здания любой сложности
Отношение применимо не только к зданиям, поэтому название общее
AMDmi3, ваше предложение, если правильно понял, подходит только для простых разноэтажных зданий, которые можно разрезать по вертикали (например, жилых домов). Но для более сложных зданий (торговых центров, вокзалов и т.д.), где каждый этаж представляет собой внутри единое целое, лучше подходит разрезание по горизонтали с использованием тегов building:part=yes и building:min_level=*. После некоторых размышлений склонился к тому, что и для жилых домов проще использовать этот вариант, за исключением пристроек. Причём чем сложнее дом, тем удобнее именно разрезание по горизонтали, получается меньше полигонов.
А насчёт отношения, может лучше приспособить отношение building: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings
Всё равно оно ещё нигде не поддерживается, логичнее использовать для зданий отдельный тип отношения. К тому же этот пропозал именно для зданий более универсальный, позволяет добавлять входы и POI. А для частей сложного здания можно добавить роль part.
При этом контур здания (outline) можно рисовать отдельным полигоном и включать в отношение, тем самым сохраняя совместимость со старой схемой.
Моё предложение подходит для обоих вариантов, как резать - дело хозяйское.
Во-первых, моё предложение подходит не только для зданий, во-вторых, не хочется пихать в одно отношение всё подряд.
Я хочу задать способ описать форму сложного объекта, а уж его потом можно включить и в building и в address.
Он поможет нормально обозначить здание для тех, кому нафик не сдалась этажность. А все извращения с этажностью должны быть в дополнение к стандартному и общепринятому обозначению зданий, и никак ему не мешать.
Всего что имеет площадь и высоту. Куча man_made, natural, historic.
Я лично вообще не вижу смысла объединять в отношение здание с его входами и poi, потому что входы и poi к нему и так отнесены своим положением. Вот poi со входом объединить было бы куда логичнее.
Я уже это сто раз сказал. И вопрос не в том, что мне она не нужна (она мне нужна), а в том, что имеющиеся средства задаче абсолютно не соответствуют.
Но так как большинство здесь собравшихся этого не понимают, сейчас речь идёт о том, чтобы ваши потуги впихнуть невпихуемое создавали поменьше проблем всем остальным.
Т.е. я правильно понял что по схеме AMDmi3 чтобы замапить здание переменной этажности (3 и 5 этажей) с колодцем (колодец для того чтобы проиллюстрировать зачем нужен inner) чтобы это устроило liosha надо
Создать 4 вея
Первый 1(2)36(5)41 - это outline, видимо outer, либо прям такую роль (outline) и завести
На него building=yes, адрес, и возможно общее количество этажей /высота если здание разбивалось горизонталями (как останкинская башня)
Второй 12541 - это 3х этажное здание - outer,
На него building:part=yes building:levels=3 и т.д.
Третий - внутренний контур в роли inner
Без атрибутов видимо
Ну либо второй и третий в отношение мультиполигона и на отношение building:part=yes building:levels=3 и т.д.
Четвертый 23652 - outer
На него building:part=yes building:levels=5 и т.д.
Ну и релейшн relation: type=physical
Только непонятно куда общие для здания атрибуты вешать, если удовлетворять требования liosha - на outline если AMDmi3 то как то логичнее на само отношение.
А как быть если тип здания, адрес и общая этажность не совпадает с outline?
Классический пример: девятиэтажный дом с пристройкой. Дом загнут буковой Г и имеет адрес “Лесосечная 3”. Пристройка двухэтажная и имеет адрес “Лесосечная 3/1”. Можно легко отыскать и более сложные примеры. Например, дом “лесенкой” в 7-9-11 этажей. Сколько ставить на контур?
FYI, ролями в мультиполигоне выступают не полигоны а любые веи. Требование только одно: чтобы внешние и внутренние границы образовывали замкнутые контуры и внешние контуры не пересекались.
Название type=physical неочевидное. Я бы предложил все же type=building, причем его участниками должны быть не произвольные веи, а именно полигоны.
Я понял. Только ж этажи никуда не денутся, и ты, вместо того, чтобы опускаться до коллег из соседних проектов, которые постановляют за всех не маппить пешеходные дорожки, парки и далее по списку, мог бы быть более конструктивным и поучаствовать в обсуждении того, как это маппить чтобы это всех устроило.