Uk:Relation:multipolygon

Зв’язок типу мультиполігон використовується для створення комплексних полігонів.

Прості полігони створюються в OSM за допомогою однієї замкненої лінії і позначення будь-яким теґом, що має на увазі полігон, а не замкнену лінію. Наприклад, замкнена лінія, позначена landuse=forest, буде тлумачитись, як полігон, в той час як лінія з теґом junction=roundabout — ні.

Однак, дана модель працює тільки з полігонами, які складаються з однієї лінії і не мають отворів. Будь-який інший полігон, що є складнішим за цей (наприклад: берегова лінія, що складається з послідовно з’єднаних ліній, або полігон, що складається з кількох нез’єднаних частин, або такий, що має отвори) потребує використання зв’язку мультиполігон.

Якщо коротко, зв’язок мультиполігон може складатись з кількох ліній, що мають роль outer (зовнішній периметр) та кількох ліній з роллю inner (отвори), і вони повинні утворювати вірні замкнені межі для утворення форми мультиполігону.

В основному в Німеччині type=multipolygon використовувався замість type=boundary для створення зв’язків кордонів. Цей метод не набув широкого поширення і вважається застарілим.

Теґи

Члени

Використання

Використання мультиполігонів передбачає наступне:

• Теґи, що описують мультиполігон (напр. landuse=forest) повинні призначатись зв’язку. Лінії, що утворюють зовнішній периметр, повинні лишатись без теґів, за виняток випадків, коли вони позначають самостійні речі. Наприклад, ліс може бути окреслений чотирма парканами, в цьому випадку кожна лінія буде позначена теґом паркану barrier=*, але вони все ще можуть бути використані як члени зв’язку з роллю "outer", що утворюють зовнішній периметр лісу.
• Якщо у вас є одна замкнена лінія і вона не описує щось сама по собі, ви можете лишити зв’язок без теґів, призначивши їх цій лінії. Якщо ви маєте більше ніж одну зовнішню лінію (див. "Розширені Мультиполігони" нижче), це не матиме жодного сенсу. Передбачається (для підтримання цілісності) завжди додавати теґи мультиполгону до зв’язку.
• Якщо внутрішня лінія представляє щось сама по собі (напр. ліс із отвором, де отвір є озером), внутрішня лінія може бути позначена відповідним чином.
• В іншому випадку внутрішні лінії повинні лишатись без теґів.
• Спрямованість ліній значення не має.
• Послідовність членів зв’язку також не має значення (але правильно відсортовані списки членів можуть допомогти редакторам в перевірці повноти інформації).

Вагомі умови для мультиполігонів

Загалом, зв’язки мультиполігони можуть використовуватись для створення мультиполігонів у відповідності до стандарту OGC Simple Feature (Графічні приклади дійсності OGC). Будь-що, що не відповідає стандарту (напр. мультиполігони із самоперетином) повинне вважатись недійсними зв’язками мультиполгонами, із важливим виключеннями, щодо внутрішніх отворів, що доторкаються між собою (див. нижче).

Ми визначаємо дійсним (замкненим) полігоном з'єднання підмножини ліній (членів), які утворюють замкнений полігон, коли їх кінці з’єднані між собою.

Ми визначаємо незамкнену лінію, як комбінацію точок, в якій координати першої точки відрізняються від останньої.

Дійсним зв’язком мультиполігоном, є зв’язок, що відповідає наступним вимогам:

• Лінії члени мультиполігону ПОВИННІ утворювати один чи більше замкнений полігон, коли лінії, що належать зв’язку, з’єднанні таким чином, що вони утворюють один чи більше замкнений ланцюг.
• Рівно дві незамкнені лінії, і не більше, повинні мати спільну кінцеву точку (напр. крайні точки ліній показані чорними крапками на малюнках).
  • Якщо кінцева точка належить менше ніж двом лініям, полігон не може вважатись замкненим і є погано сформованим. поганий приклад 1
  • Якщо кінцева точка належить більше ніж двом лініям, замкнений полігон не може бути реконструйований однозначно. поганий приклад 2 (Виключення – точки, що належать парному числу незамкнених ліній повинні бути частиною внутрішніх отворів, що дотикаються друг друга.)
• Внутрішні полігони не повинні перекривати зовнішні полігони чи дотикатись них. Перекриття можливо усунути повною переробкою мультиполігону.

Приклади

<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="inner" />
</relation>

<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="inner" />
  <member type="way" id="3" role="inner" />
</relation>

<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="outer" />
  <member type="way" id="3" role="inner" />
</relation>

<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="outer" />
</relation>

<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="inner" />
  <member type="way" id="3" role="inner" />
  <member type="way" id="4" role="outer" />
  <member type="way" id="5" role="inner" />
</relation>

<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="outer" />
  <member type="way" id="3" role="outer" />
  <member type="way" id="4" role="outer" />
  <member type="way" id="5" role="inner" />
  <member type="way" id="6" role="inner" />
  <member type="way" id="7" role="inner" />
  <member type="way" id="8" role="inner" />
  <member type="way" id="9" role="inner" />
  <member type="way" id="10" role="inner" />
  <member type="way" id="11" role="inner" />
  <member type="way" id="12" role="outer" />
  <member type="way" id="13" role="outer" />
  <member type="way" id="14" role="outer" />
  <member type="way" id="15" role="outer" />
  <member type="way" id="16" role="inner" />
  <member type="way" id="17" role="inner" />
  <member type="way" id="18" role="inner" />
  <member type="way" id="19" role="inner" />
  <member type="way" id="20" role="outer" />
</relation>

<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="inner" />
  <member type="way" id="3" role="outer" />
</relation>

<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="inner" />
  <member type="way" id="3" role="inner" />
</relation>

Погані приклади

Тут містяться приклади помилкових мультиполігонів, щоб показати як НЕ треба робити

Додаткові приклади

• Додаткові приклади мультиполігонів знаходяться на сторінці Multipolygon_Examples.
• Proposition for examples of valid and invalid unusual configuration

Позначення теґами

• Пропонується застосовувати всі теґи, які описують полігон, до зв’язку, а не до ліній. У багатьох випадках це призведе до появи ліній без теґів.

• Реалізація з урахуванням сумісності:
  • Стиль креслення обирається на основі теґів самого зв’язку.
  • Якщо зв’язок не містить теґів, використовується стиль ліній зовнішнього периметру.
  • Якщо зовнішні стилі не співпадають або відсутні, це вважається помилкою.
  • Креслення внутрішніх ліній визначається їх теґами. Якщо стиль теґів внутрішніх ліній співпадає зі стилем зовнішніх ліній (старий метод), стиль внутрішніх ліній вважається незаповненим.

Стиль мапінгу, кращі приклади

Мультиполігони відкривають можливість створення геометрично ідентичних об’єктів використовуючи різні стилі: у вигляді ліній чи мультиполігонів, використовуючи замкнені і не замкнені, або спільні чи окремі лінії.

Основним питанням є: який стиль мапінгу використовувати. Деякі стилі мають переваги над іншими, і повинні розглядатись як добра практика. Для інших, вибір більше залежить від уподобань, або ж від досвідченості мапера.

В узагальненому вигляді, для великих територій, що позначаються одним і тим же теґом, може використовуватись велика кількість невеликих мультиполігонів чи замкнених ліній, чи менша кількість більших мультиполігонів. Для мультиполігонів можливі два стилі мапінгу:

Метод A

Внутрішній і зовнішній контури утворюються замкненими лініями, якщо можливо, за винятком, коли ці лінії є достатньо великими (більше ніж 2000 точок). Лінії, як правило належать одному мультиполігону

Метод Б

Кожна межа між двома мультиполігонами представляється окремою лінією, яка потім входить до складу відповідних дотичних мультиполігонів. Отже периметр мультиполігону складається з кількох відкритих ліній

Питання, який стиль мапінгу мультиполігонів використовувати, інтенсивно обговорюються впродовж останніх років, дивіться Talk:Relation:multipolygon, а також на форумах. Досі ще не досягнуто остаточного консенсусу, але використовуються наступні правила:

• Нанесення простих замкнених ліній у вигляді мультиполігонів збільшує кількість об’єктів бази даних та час їх рендерінгу. Таке додаткове підвищення складності треба уникати.
• Використання спільних ліній мультиполігонами (метод Б) дозволяє підвищити ефективність подання даних, уникаючи застосування ліній, що накладаються одна на одну.
• Мультиполігони, що складаються з незамкнених ліній (метод Б), важче обробляти недосвідченим маперам і в простих редакторах, таких як Potlatch 2, що часто призводить до випадкового руйнування таких мультиполігонів користувачами, які нічого не підозрюють.
• Багато досвідчених учасників висловлюються, щодо дискомфорту метода Б, особливо для дуже великих мультиполігонів.
• Величезні мультіполігони призводять до уповільнення процесу візуалізації.
• Редагування складної геометрії в JOSM легше, швидше і не призводить до помилок з методом А. Так як метод Б потребує вилучення, створення та вставки різних ліній до коректних зв’язків мультиполігонів.

Поки що не існує офіційних застережень, як правильно використовувати мультиполігони, до тих пір доки вони є геометрично вірними. Однак вважається, що вибір відповідного стилю мапінгу дозволить зберегти базу даних незасміченою та простою для внесення змін кожним з учасників.

Potlatch 2 приклади

На мапі трав’яниста ділянка посеред дерев:

Клацніть на зовнішню лінію:

Утримуючи Control клацніть на внутрішню лінію:

Помітили, як з’явився значок з «пончиком» на панелі інструментів:

Натисніть його:

Щоб побачити актуальні теґи, що були додані, натисніть advanced:

Мільтиполігон був створений:

Potlatch 1 приклад

В Potlatch 1, ролі для мультиполігону треба призначати його членам, а не зв’язку, В режим редагування, виділіть члена зв’язку і оберіть роль inner чи outer зі списку.

Допоміжні інструменти

• Relation Check
• OSM Inspector має підтримку перевірки мультиполігонів

Дивіться також

• Дивіться The Future of Areas, де міститься обговорення, як покращити обробку полігонів в OSM.