3D-моделирование в OSM

Лучше релейшн building чем такое использование релейшена мультиполигона.

Уважаемые, не надо трогать мультиполигон. Семантика мультиполигона уже а) отработана б) поддерживается софтом в) стоит на плечах гигаонтов. Конкретно сейчас, если кто-то поменяет семантику мультиполигона допустив, что внешние границы могут касаться больше чем в одной точке, лично у меня отвалятся: GEOS, PostGIS (на той же библиотеке) и GeoJSON. Все это придется заменить собственными велосипедами только потому что кто-то “не видит проблемы”.

Проблема с 3D маппингом в том, что семантика полигона building=yes не определена. Это линия фундамента, проекция здания на плоскость, что-то имеющее собственный адрес или что-то четвертое? Отсюда, совершенно непонятно, что должно остаться, а что можно менять.

На всякий случай поддержу. У меня проблем нет, но стандарты – это святое! Руки прочь!

Хорошо, с мультиполигонами мы уже разобрались, что их использовать не стоит. Да и лишние какие-то тут телодвижения со стороны рисующего возникают.

С другой стороны нужно как-то это дело обозначать. Я согласен с тем, что должен быть один объект, который будет охватывать весь периметр, он и должен нести в себе все основные теги, и это должен быть полигон, лучше нулевой высоты. И уже на него сверху накладывать полигоны частей здания с указанием каких-то 3-х измерений, в соседней теме было заявлено, что их надо указывать как building:part. Нужно ли связывать building:part в единый building с помощью отношения? Нет, если речь идёт о мультиполигоне.

Давайте порассуждаем вместе:
Существует 2 слоя.
1-й слой: двухмерная карта, на которой отображены все объекты в плоскости.
2-й слой: третье измерение, которое является атрибутом первого, т.е. зависимым от первого слоя слоем. 2-й слой не может повлиять на 1-й никаким образом, точнее, не должен влиять. При этом, при изменении 1-го слоя, 2-й слой должен быть изменён (передвинуть объекты, уточнить и т.д.), но не всякое изменение 1-го слоя должно касаться 2-го слоя (например, я добавил теги адреса).
Таким образом, связь 1-й слой → 2-й слой должна быть факультативной, т.е. необязательной. Раз связь необязательна, её можно не делать. Значит и связывать части здания в одно здание не надо, чтобы не смешивать разные слои.

Исходя из этого, я предлагаю следующую концептуальную схему:
0. Так как работы со слоями в OSM нет, считать слои виртуальными, т.е. их физически создавать не нужно, а лишь подразумевать.

  1. Основной виртуальный слой OSM (назовём его виртуальный слой №1) не трогать, как рисовали без разноэтажности и 3d, так и рисуем дальше. Любые наши изменения для обозначения разноэтажности и 3d не должны касаться и быть легко устранимыми, выпиливаемыми и не влиять ни коем образом на этот слой.
  2. Так как править основной виртуальный слой для добавления данных о 3d мы не имеем права, рисуем для этого в слое №2, назовём его виртуальный слой №2 “высотный”.
  3. Слой №1 и слой №2 “высотный” не должны иметь общих элементов, тегов, точек, отношений, связей и т.д., чтобы не допустить виляния слоя №2 “высотный” на слой №1. По сути, слой №2 таким образом становится лишь атрибутивным и необязательным.
  4. То, что рисуем в слое №2 не должно иметь тегов и значений, используемых в слое №1, чтобы не вызвать путаницу между слоями. Соответственно, то что в слое №2 не должно рендериться в стандартных рендерах вообще.
  5. Рендер слоя №2 должен осуществляться только альтернативными рендерами.

Техническая реализация данной концептуальной схемы:

  1. Слой №2 предпочтительно хранить в отдельной БД,либо, в крайнем случае, виртуально ограничивать его применение.
  2. В слое №2 должны быть теги, не используемые в слое №1
  3. В слоях №1 и №2 не должно быть общих элементов, в т.ч. отношений и точек.
  4. По хорошему, слой №2 должен строиться как отдельный проект, основанный на данных OSM, таким образом будет установлена односторонняя связь от слоя №1 к слою №2.

Воистину так. Как бы ещё это до людей донести…

Ну для меня не сразу это было ясно, а только после рассуждений, т.е. путём логики.

Данные имеют свойство устаревать. Если синхронизации не будет - отдельная база довольно быстро превратится в помойку.

Разговоры разговаривать тут бесполезно. Будет отдельный живой проект - станут пользоваться им. Не будет - будут пользоваться тем, что есть.

да-да. несмогли дотерпеть до туалета - насрали посреди площади.

Базовые возможности для высотности и этажности должны быть прямо в ОСМ. В навигаторах есть трёхмерный режим, и недалёк тот день когда они будут рисовать 3Д-здания и всякие трубы и вышки.

В отдельном проекте хорошо рисовать полностью трёхмерные модели с текстурами и остальными плюшками.

Ваш юмор, как всегда, искромётен. :slight_smile:

Не знаю, базовые возможности и сейчас есть. Однако разноэтажные здания сейчас невозможно правильно обозначить. Я вижу в этом цепочку составляющих: указание этажности для простых зданий — указание этажности для разноэтажных зданий — привязка дорог к рельефу — рисование оврагов, развязок и мостов — рисование зданий со сдвигом по высоте — рисование всевозможных “дырок” по вертикали в зданиях — рисование элементов зданий типа балконов — текстуры. На каком этапе нужно остановиться и сказать: “Дальше в OSM” не нужно развивать 3д, это уже не базовые возможности"? Дырки в зданиях по высоте? Сдвиг по высоте периметра здания? Что именно? Разная этажность? Я лично хочу обозначать третье измерение, но как? и где? Поэтому я и выдвинул концептуальную модель, в которой, собственно, слои ВИРТУАЛЬНЫЕ, т.е. они разделены, но виртуально. Чтобы в любой момент можно было бы выделить третье измерение и его либо перенести и развивать самостоятельно, либо удалить как мусор. А как реализовать одностороннюю связь? Как сделать так, чтобы 2-й слой не влиял а 1-й? У меня куча вопросов, и я не могу на них ответить, т.к. я не программист, я не понимаю, как это всё реализовано и как всё это реализовать. И я делаю выводы на основании того, что есть и что понимаю.

Делается сторонняя база любой сложности, а в осм нужным объектам ставится тег типа custom:shape=<id объекта в сторонней базе>.
По-моему, очевидно.

К счастью виртуальные слои работать не будут. Слишком сложно реализовать, слишком сложно маппить, слишком сложео протолкнуть. Сторонний сервис это даже не смешно. Откуда возьмется инфраструктура? Сервера? Редакторы? Кто будет поддерживать связь? Как привлечь людей маппить 3D там, а не в OSM? Что делать с building:levels/building:height?

Раз уж никто не может сказать, что конкретно обозначает building=yes (или что считать зданием), может считать что building=yes это часть здания фиксированной высоты. Ничуть не хуже фундамента или проекции. Если кому-то нужны плоские здания, прекрасно, пусть строит проекцию (объединяет полигоны по union) или выбирает полигоны, которые покоятся на земле, в зависимости от потребностей.

Я за building:height, building:min_height + отношение building. Недостатки те же, что и так есть. Несовпадение элемента адресации с полигоном building=yes есть и сейчас. В любом случае эту проблему придется решать. Отсутствие поддержки в редакторах. При любой схеме ее не будет до тех пор пока не сделают.

Зато плюсы у такой схемы огромные:

  • Она позволяет маппить подавляющее большинство зданий

  • Она совместима с тем, что замаплено уже сейчас

  • Она достаточно проста

  • Позволяет ровно ту точность, которую может дать сообщество любителей

Пока резюмирую то, что обсудилось в IRC. Позже можно сделать пропозал.

  1. Одно здание должно быть одним объектом. Очевидно, что в нетривиальных случаях, как-то здание состоящее из частей разной высоты, этим объектом один полигон быть уже не может и надо использовать отношение.
  2. Существующие отношения не подходят. В частности, самое очевидное (мультиполигон) потому что
    а) Не позволяет использовать касающиеся внешние контуры.
    б) Тем более, не позволяет использовать пересекающиеся внешние контуры.
    в) Не позволяет задавать тэги на частях
    г) (что следует из в) - никак определяет что делать когда тэг проставлен и на контуре и на отношении.

Нелюбителям 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) можно рисовать отдельным полигоном и включать в отношение, тем самым сохраняя совместимость со старой схемой.

Именно это и нужно. При чём именно на этот контур повесить все теги, относящиеся к самому зданию - тип, адрес, общую этажность etc.

Моё предложение подходит для обоих вариантов, как резать - дело хозяйское.

Во-первых, моё предложение подходит не только для зданий, во-вторых, не хочется пихать в одно отношение всё подряд.
Я хочу задать способ описать форму сложного объекта, а уж его потом можно включить и в building и в address.

И получится то, что ты называешь фейком.

Нет, получится стандартный и общепринятый объект, обозначающий здание

Все части здания, включая всякие башенки на верхних уровнях, включать в роли outer?

А для чего ещё, например?

Создавать по несколько разных отношений для одного здания тоже не хочется.