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

http://forum.openstreetmap.org/viewtopic.php?pid=127413#p127413

Ну лично я выступаю за вариант “не заниматься ерундой” :slight_smile:

Если он кого не устраивает, то можно придумать кучу схем.
Одно но: они должны быть прозрачны для тех, кому они не интересны. Собственно, как и обычно.

А. Я думал, как дома из кусков собирать.

Что-то ты сам себе противоречишь.

Мультиполигон с касающимися outer’ами абсолютно прозрачен и совместим с мультиполигоном без касающихся outer’ов.

Вот: http://sovok.ucoz.ru/osm/62.osm
Как это здание привести к валидному мультиполигону?

Исходя из слов Лёши, к валидному мультиполигону его никак нельзя привести. А по мне - перенести тэги с большого полигона на отношение, удалить его и соединить общие точки у маленьких полигонов, так http://amdmi3.ru/files/62.osm .

PS. А entrance уже где-то задокументированы/приняты? Зело нравятся.

Получается, “обозначай как хочешь”? Если можете, напомните мне пропозал, где здание рисовалось дырками по высоте, может там есть какое-то решение.


Входы пока пропозал, даты голосования пока не назначено.

Довольно многое можно обозначать по-разному, при этом иногда “официально” это не обозначить вообще никак. “Как хочешь” варьируется в широких пределах - одно нельзя будет вменяемо интерпретировать, другое можно. Вот тут мне кажется невменяемо интерпретировать (не учитывая тэгов на 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 чем такое использование релейшена мультиполигона.