Не тот пример. Говорилось о том, что дырка не должна превращать бублик в откусанный бублик.
Тут inner касаются, а не outer. Я сам толком не знаю, но более опытные в вопросах структуры данных OSM люди тогда высказались резко против. Конечно, я понимаю, всем хотелось бы, чтобы было проще. Вон на западе я где-то видел, как вообще не заморачиваются с building:part , каждую часть здания отмечают как building, а адрес на точке. Но русское сообщество традиционно не ищет лёгких путей.
Пример не тот, я для картиночности его вставил.
Не нашёл либо не понял по текущему английскому тексту требования (**outer “не должны касаться” **)
http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Valid_Multipolygon_conditions
Это какая-то программа просто такое не поддерживала(ет)?!
Т.е. если стереть way#1 на картинке, а из #2 и #3 сделать мультиполигон, у которого 2 outer (#2, #3) будут “касаться” то это будет правильным, разве нет?
Давно было наверное. Против мультиполигонов и отношений в целом - потому что их не все программы хорошо поддерживали сразу.
Всё правильно. Поле+лес, промзона+жилая застройка, да что угодно, в принципе.
LLlypuk82: вопрос был в том, могут ли два касающихся outer принадлежать ОДНОМУ мультиполигону. На данный момент достигнуто соглашение, что нет. А вот по поводу вопроса, могут ли касаться разные inner от одного мультиполигона единой позиции не выработано. Keepright, например, считает такое за ошибку, в отличие от вики.
Ну вот собственно и вопрос зачем это и кем принималось.
Я перечитал http://wiki.openstreetmap.org/wiki/Relation:multipolygon ещё раз и особенно секции #Usage и #Valid_Multipolygon_conditions , но не нашёл упоминания почему это неправильно и что так делать нельзя.
Мультиполигоны достаточно гибкая штука:
- любое количество “замкнутых” последовательностей линий
- innner и outer линии не должны иметь общих точек (ошибка 2D-топологии, когда смешивается “внутри и снаружи”)
Кроме этого есть несколько советов как не делать, в основном они связаны с тем что что-то не поддерживается.
По поводу тегов на мультиполигоне нашёл что явно советуют теги на отношении держать, с той же страницы:
Предлагается (для единообразия) всегда указывать теги мультиполигона на отношении.
Невнимательно прочитал.
Если речь о двух членах внутри одного отношения multipolygon, имеющих роль outer, то это что-то оригинальное и слабо представимое (мной, например).
Россия и Калининград?
Два контура outer: один Россия (из нескольких way/линий) и Калининград (из нескольких way/линий).
Причём внутри каждого из них может быть полный хаос из иерархий inner-outer-inner (главное чередавать роли).
Накидал примеры для понимания темы:
(Ниже просили уточнить: да, все relation на картинке - мультиполигоны)
Способы тегирования 1,2,3 все правильные. Каждый из них имеет свои плюсы и минусы, и более или менее предпочтителен в разных случаях. Если здание простое, как на картинке, обычно рекомендуется делать как в примере 1. Если оно очень длинное и сложное, часто рисуют как 3. Если нижняя часть характерно выделяется по каким-либо признакам, лучше всего 2. Также возможна и схема building:parts=horizontal, где все три объекта - здание и части - составные мультиполигоны, или, наоборот, все три обычные полигоны. Но у данного здания (как и у большинства в реальности) контур нижних этажей полностью повторяет общий контур building. Поэтому такие варианты схемы horizontal будут означать или две полностью совпадающих линии, или два отношения с одинаковыми членами, что нежелательно. Однако, если в здании есть подворотни и т.п., они также допустимы.
Наконец, возможна комбинация всех трёх способов (building:parts=mixed)
Спор, как я понимаю, идёт по поводу последней картинки. Однако, этот способ неправильный. И дело не только в вопросе, могут ли касаться outer мультиполигона или нет. Если использовать схему разрезания здания по горизонтали, разные части будут пересекаться наложением. Тогда объединять их в мультиполигон нельзя по определению. Также возможны случаи, когда отдельные части представлют сами из себя мультиполигоны, т.е. предполагается мультиполигон из мультиполигонов, что тоже невозможно.
Другое дело, если в примере 4 отношение будет не мультиполигоном, а, например, уже упоминавшимся выше type=building. Но тогда тег здания и прочие сопутствующие теги (адрес и т.д.) придётся поместить на отношение, которое мало где поддерживается. Отмеченные таким образом здания перестанут рендериться везде , плюс выпадут из глобального адресного поиска. То есть, возможно, такой вариант и неплох. Но если вводить именно его, то надо это делать сразу и централизованно. Постепенные изменения, которые могут быть задокументированы со временем, здесь невозможны в принципе. Ибо сопротивление сообщества будет таким, что эта схема просто не доживёт до сколь-либо массового распространения.
Да, спору нет, так тоже можно.
Хотя 1 способ я не понимаю, теперь это можно отношением красную линию переобозначить.
Вот дальше вы объясняете это схемами разрезания по горизонтали и вертикали, но мы здесь кислое с пресным сравниванием.
Повторю пример 4 здесь:
relation #4:
building=yes
building:levels=5
outer: way#1
outer: way#2
Согласно английской странице мультиполигон такое тегирование правильное (потому что ни один пункт “нельзя” не нарушен).
Однако дальше тег building:parts=* вносит свои коррективы.
Поэтому нужно более ясно определить как работает building:parts=* либо продолжить разбирать абстрактный пример 4, но без этой схемы.
Лично я тегирую 4 способом, без использования building:parts=. Mapnik при таком подходе рисует name= с отношения на каждой линии-участнике, iD считает это “домом”.
Забавно, но англичане такими вопросами вообще не задаются, у них даже Тауэр кусками bulding=castle накрошен. Я же считаю что они лентяи и тегруют неверно 
building:parts=* - это просто тег-указатель на то, что здание состоит из частей; а его значения показывают тип “разрезания” на части:
http://wiki.openstreetmap.org/wiki/RU:Key:building:parts
Дело в том что эту информацию можно получить просто посчитав все “outer” цепочки у “мультиполигона”. Т.е. в “неправильном” 4м примере там только 2 цепочки и можно сказать что там две части (они же затегированы как building:part=yes) здания.
Имеет смысл такое?
Мне казалось что этот тег можно не указывать когда пользуешься bulding:part=yes
Собственно если сейчас открыть bulding:part то там не требуется чтобы building:parts указывалось у родительского отношения (или окружающей линии).
Что же будем делать, оставим 4 вариант как “рабочий” или изменим страницу building:part=yes?
PS. опечатался здесь сначала
Адресная информация — на контуре building (обеспечивает совместимость).
На странице RU:Simple 3D Buildings заявлено, что:
И там же:
На данный момент работает, как раз, второй случай, а первый — устарел (поскольку для рендеринга необязательно (но — для порядку — желательно) даже отношение building).
Но здесь нет общих точек.
На картинке какое-то, простите, извращение Danidin9 не ищет лёгких путей.
Да и корректно ли такое? В отношении не упомянут синий контур. Само отношение экзотическое (сиречь — самопальное, не имеющее аналогов на практике и даже в теории!). По-моему — чушь и отсебятина, работать не будет.
Поправьте меня (желательно с примерами рабочими).
Согласен полностью.
Он и номер дома будет дублировать, скорее всего. Это плохо.
Вообще-то, relation #1 (жёлтое) в этом примере - type=multipolygon, а не type=building. Было бы хорошо, если бы Danidin9 указал это на картинке.
И там всё будет работать и работает. Примеры? Делал я когда-то одно здание таким способом:
“relation #1”: http://www.openstreetmap.org/relation/3161598
“way #1”: http://www.openstreetmap.org/way/200896032
Ах да, совсем забыл. На MapSurfer.NET это выглядит отлично: http://openstreetmap.ru/#map=19/48.7479/37.61442&layer=S . И на F4Map, и на OpenScienceMap тоже.
Но если подходить к вопросу совсем правильно, то я считаю это некорректным, когда outer-ом в мультиполигоне building=* выступает полигон с building:part=. Не вызовет ли это конфликтов?
Поэтому я рекомендовал бы “way #1” оставить вообще без тегов, но зато включить его в два отношения-мультиполигона (одно - building=, другое - building:part=*)
edward17, вы скрестили, зачем-то, симпл 3-д и мультиполигон. Причём, сам мультиполигон не содержит тегов этажности (только адреска и тип сечения)
И
я тоже. Так что пример ваш некорректен (в смысле корреляции с обсуждаемой картинкой) и сам по себе довольно экзотичен (гибрид получается), однако, показательно, что и такое работает.
Создатели схемы Simple 3D Buildings, позиционируя её в качестве альтернативы для мультиполигональной схемы отрисовки зданий в объёме, не ввели логически и функционально завершающий элемент. А именно — способ рисования «бубликообразных» конструкций или пустоты внутри контуров зданий.
Уже предлагал варианты, но повторюсь: надо расширить схему всего одной ролью для членов отношения type=building. Эта роль для контура может обзываться, например, «hole» или «void», как угодно ещё. Но смысл один: обозначение пустот.
Договориться о поддержке с тем же F4map (что-то он заглох, кстати) и opensciencemap.org, по идее, можно (стали же они использовать схему в теперешнем виде), разве что mapnik «уговаривать» придётся (но чем чёрт не шутит?).
Выступаю за упрощение.
Под номером 9 расписано два варианта:
- ввести нулевое значение тега этажности
- исключая тег этажности, ввести новую роль
Также считаю принцип «максимальная этажность на внешнем контуре» бессмысленным.
Ух ты, а где прописано это позиционирование?
И хотелось бы увидеть ссылку на документацию “мультиполигональной схемы отрисовки зданий в объёме”, которая существовала до появления Simple 3D Buildings.
LLlypuk82,
Где в схеме Simple 3D Buildings написано, что нельзя использовать мультиполигоны? Вопрос “замкнутая линия или мультиполигон?” вообще не относится к данной теме. И то, и другое - способы задания полигонов. Какой из них использовать - зависит от стиля маппинга каждого отдельного маппера.
Поэтому, пожалуйста, не нужно рассказывать о том, что в схеме Simple 3D Buildings не хватает тегов для “дырок в бублике”. Для этого как раз предназначены мультиполигоны.
Эта схема самостоятельная. Неужели это не очевидно? Предложена для упрощения/облегчения (название говорящее) 3-d mapping-а. Случаи с «бубликами» не рассматривались и вообще не упоминались в ней, равно как и схема multipolygon (которую, тогда уж, следовало упомянуть, как исключительный случай, но это не было сделано).
Они ни для чего не предназначены, а — сами по себе. И они самодостаточны, в отличие от обсуждаемой «облегчёнки». Комбинирование же схем (в рамках одного здания) — редчайший случай (то, что я называю «экзотика») и элемент нестандартности.
Никто не покушается на ваш стиль маппинга
Встречная просьба: не следует указывать другим, что им делать, а что — нет.