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

Довольно многое можно обозначать по-разному, при этом иногда “официально” это не обозначить вообще никак. “Как хочешь” варьируется в широких пределах - одно нельзя будет вменяемо интерпретировать, другое можно. Вот тут мне кажется невменяемо интерпретировать (не учитывая тэгов на member’ах) просто нельзя.

В каком месте?
Я всегда считал глупостью попытки использовать модель данных осм для того, для чего она не подходит - будь то (по нарастающему градусу глупости) белорусская адресация, схемы общественного транспорта, или вот теперь 3д-моделирование .

Просто если раньше глупость легко отфильтровывалась, то сейчас началось перепридумывание давно общепринятых значений, и как следствие засирание базы фейковыми объектами.

Несовместим. Именно потому что неоднозначный.
Попробуй посчитать его периметр, например.

Честно говоря, не вижу никакой проблемы. Два смежных сегмента outerов не являются частью границы объекта, описываемого мультиполигоном2, вот и всё.

Или считаются

http://iceimg.com/51aecec5357158.png.htm

building = yes
building:shape = tower
height = 18
man_made = tower
name = Останкинская телевизионная башня
tower:type = communication

здание высотой 18 метров
круто.
и никакого вменяемого способа получить правильные данные в масштабах хотя бы области. не говоря уж о стране.
зато целых 42 полилинии и 492 точки никак не соответствующие ничему существующему в реальности
отличный подход.

Плохой подход. Здание сделано для лулзов, так что не приписывайте мне всякой ерунды. Я против подобного.

В чем проблема с периметром, и периметр чего вы вообще собираетесь считать? Фундамента? Фундамент там не обозначен.

Только сейчас посмотрел файл, до этого не заметил, только перечитав увидел. И что, делать 2 inner, без outer? Может 2 outer без inner?

//Плохой подход. Здание сделано для лулзов, так что не приписывайте мне всякой ерунды. Я против подобного.
Hind, может тогда вернем высоту 540? А Котяру попросим обрабатывать что-то в духе building_part:height=18? Я в соседней теме написал уже)

Высоту, конечно, нужно вернуть. Странно, что удаливший башню этого не сделал.

Это очень большая экзотика.
Пересекаться, значит, иметь хотя бы одну общую точку.
Вопрос в том, входит ли граница в состав площадного объекта или нет.
Если входит, - пересекаются.
Если не входит, - не пересекаются и НЕ КАСАЮТСЯ.
Касаться могут в одном единственном случае, - когда в один из объектов граница входит, а в другой - нет. А такое положение как раз и есть большая экзотика.

Отнюдь.
Все вполне логично: внешние считаются с границей, внутренние - без. И то, что для внутренних и внешних граница учитывается по-разному, - тоже вполне логично (именно, чтобы избежать неоднозначностей).

Вопрос в другом: существующая система node/way/relation эклектична и имеет ряд серьезных ограничений, которые и приводят к созданию подобных топиков.
По-хорошему, нужно вводить еще один элемент - объект, переносить на него часть свойств, присущих сегодня отношениям, а также объявлять все три предыдущие сущности (node, way, relation) несамостоятельными, т.е. допускаемыми ТОЛЬКО как элемент объекта. Вот этот последний момент, увы, трудноосуществим, т.к. потребует порождения массы новых объектов, например, по одному на каждую POI, улицу, дом и т.п. Не говоря о потере преемственности и переписывании всего софта.

Я, кстати, тоже считаю это нормальным.

И присоединяюсь к следующему:

Собственно, когда вносятся какие-то изменения, то нужно думать о том, как это может быть воспринято софтом. Не в том смысле, что подгонять под возможности существующего софта, но в том, чтобы в первую очередь прикидывать, чтобы не было неопределенности при обработке тех или иных объектов.

Лучше релейшн 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.

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

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

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

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

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