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

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

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

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

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

Базовые возможности для высотности и этажности должны быть прямо в ОСМ. В навигаторах есть трёхмерный режим, и недалёк тот день когда они будут рисовать 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?

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

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

И как он поможет обозначить здание из двух частей разной этажности?

Он поможет нормально обозначить здание для тех, кому нафик не сдалась этажность. А все извращения с этажностью должны быть в дополнение к стандартному и общепринятому обозначению зданий, и никак ему не мешать.

Да. part, если угодно.

Всего что имеет площадь и высоту. Куча man_made, natural, historic.

Я лично вообще не вижу смысла объединять в отношение здание с его входами и poi, потому что входы и poi к нему и так отнесены своим положением. Вот poi со входом объединить было бы куда логичнее.

Так и скажи - выкинуть этажность, потому что тебе лично она не нужна.

Я уже это сто раз сказал. И вопрос не в том, что мне она не нужна (она мне нужна), а в том, что имеющиеся средства задаче абсолютно не соответствуют.

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