Pl:Relation:multipolygon

From OpenStreetMap Wiki
Jump to: navigation, search
Dostępne języki — Relation:multipolygon
· Afrikaans · Alemannisch · aragonés · asturianu · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · Bân-lâm-gú · Basa Jawa · Baso Minangkabau · bosanski · brezhoneg · català · čeština · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · latviešu · Lëtzebuergesch · lietuvių · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · português do Brasil · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · беларуская · български · қазақша · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · मराठी · हिन्दी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 吴语 · 粵語 · 中文(繁體)‎ · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް
Logo. type=multipolygon
One example for type=multipolygon
Description Pomóż przetłumaczyć na polski!
Relacja używana do reprezentowania złożonych obszarów.
Grupa

Properties

Role pomoc

  • Way - outer
  • Way - inner

Statystyka użycia

Filtrowanie danych używając Overpass turbo:

Filtrowanie danych OSM z tym tagiem, używając Overpass turbo (via overpass turbo - help)
Relation:multipolygon - służy do reprezentowania złożonych obszarów.

Proste obszary są odwzorowywane w OSM, tworząc jedną kołową linię i tagowanie jej czymś, co sugeruje obszar zamiast zaokrąglony kontur. Na przykład, zaokrąglony kontur oznaczony jako landuse=forests będzie można uznać za obszar, natomiast zaokrąglony kontur oznaczony junction=roundabout nie będzie.

Jednak model ten działa tylko na obszarach, z których kontur składa się z jednej linii i który nie ma otworów. Każdy obszar, który jest bardziej złożony niż ten (np. ponieważ jego kontur składa się z kilku linii połączonych ze sobą, lub powierzchnia składa się z wielu niezależnych części lub ma dziury) wymaga multipolygon relację.

type=multipolygon miał zastosowanie głównie w Niemczech, zamiast type=boundary dla relacji granic. Metoda ta nie była powszechnie zaakceptowana i powinna być zaniechana.

W skrócie, relacja multipolygon może mieć dowolną liczbę linii w roli outer (zarys zewnętrzny) i dowolną liczbę linii w roli inner (zarys wewnętrzny), a te znowu muszą, w jakiś sposób, utworzyć z nich wielokąt.

Oznaczenia

Klucz Wartość Opis
type multipolygon Mówi aplikacji do korzystania z zasady budowania obszaru opartego na elementach.

Elementy

Way lub Node Role Ilość Opis
Way outer jedna lub więcej Linia tworząca pierścień zewnętrzny danego obszaru.
Way inner jedna lub więcej Linia tworząca pierścień wewnętrzny danego obszaru.
Way none Nie używać, przestarzałe. Narzędzia powinny sobie z tym poradzić, jak z linią "outer".
Way enclave Nie używać, przestarzałe. Narzędzia powinny sobie z tym poradzić, jak z linią "inner". Kiedyś była głównie używana w relacjach granic.
Way exclave Nie stosować, przestarzałe. Narzędzia powinny sobie z tym poradzić, jak z linią "outer". Kiedyś była głównie używana w relacjach granic.

Użycie

The intended use of multipolygons is this:

  • Tags describing the multipolygon (e.g., landuse=forest) should go on the relation. The outer way(s) should be left untagged, unless they describe something in their own right. For example, a forest could be delineated by four fences, in which case the four ways would be tagged with the barrier tag, but could still be used as "outer" members of the forest relation.
  • If you have one closed way making up the outer ring and it does not describe something in its own right, you may also put these tags on the outer ring and leave the relation untagged. If you have more than one outer way (see "Advanced Multipolygons" below), then this does not make sense. Therefore it is suggested (for consistency) to always put the multipolygon tags on the relation.
  • If the inner way represents something in itself (e.g., a forest with a hole where the hole is a lake), then the inner way may be tagged as such.
  • Otherwise the inner way(s) should be left untagged.
  • The direction of the ways does not matter.
  • The order of the relation members does not matter (but properly sorted member lists can help human editors to verify completeness).

Prawidłowe warunki dla wielokąta

Generally, the multipolygon relation can be used to build multipolygons in compliance with the OGC Simple Feature standard (Graphical examples of OGC validity). Anything that is not a valid multipolygon according to this standard (e.g., polygons with intersecting rings) should also be considered an invalid multipolygon relation, with the notable exception of touching inner rings (see below).

We define a valid (closed) polygon as the combination of a subset of member ways which, when their endpoints are joined, form a closed polygon.

We define an unclosed way as a combination of nodes in which the first node is different than the last node.

The conditions to form a valid multipolygon relation are the following:

  • Member ways of a multipolygon relation MUST form one or more closed polygon(s). When the ways belonging to the relation are combined they must form one or more closed chains. [[1]]
  • Exactly two unclosed ways, and no more should share an endpoint (eg. the most extreme nodes of a way represented by the black dot in the images).
    • If an endpoint is shared by less than two unclosed ways, the polygon can't be closed and is ill formed. invalid example 1
    • If an endpoint is shared by more than two unclosed ways, it's ill formed and a closed polygon can't be reconstructed unambiguously. invalid example 2 (Exception - points shared by an even number of unclosed ways might be part of touching inner rings which is ok.)
  • Inner polygons must not overlap with outer polygons or touch them. Overlapping can be avoided completely by reshaping.

Przykłady

Jeden zewnętrzny i jeden wewnętrzny pierścień

Edycja w JOSM
W starym stylu, powszechnie używana "relacja:multipolygon" zezwalała tylko na jeden pierścień zewnętrzny i dowolną liczbę pierścieni wewnętrznych; Pierścienie miały składać się z tylko jednej pojedynczej linii zamkniętej. Ten rodzaj wielokąta (naprawdę nie wielo kąta ale wielo linii) jest oczywiście nadal obsługiwany, ale zasady zostały złagodzone tak, że jest to tylko szczególny przypadek ogólniejszej Relation:multipolygon.
<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="inner" />
</relation>
Szkic 1: Jeden zewnętrzny i jeden wewnętrzny pierścień

Jeden zewnętrzny i dwa wewnętrzne pierścienie

<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>
Szkic 2: Jeden zewnętrzny i dwa wewnętrzne pierścienie

Wiele linii, tworzących pierścień

Zaawansowany schemat "multipolygon" pozwala każdemu wewnętrznemu lub zewnętrznemu pierścieniowi składać się z więcej niż jednej linii łamanej. Jest to przydatne dla wielokątów obejmujących bardzo duże obszary, gdzie byłoby to bardzo niepraktyczne, aby mieć jedną linię łamaną biegnącą wokół całości:
<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>
Szkic 3: Multiple ways forming a ring

Dwa rozdzielone pierścienie zewnętrzne

W przeciwieństwie od starego stylu wielokąta, zaawansowana relacja "multipolygon " pozwala również na dowolną liczbę pierścieni zewnętrznych, a tym samym aby były prawdziwymi wielokątami:
<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="outer" />
</relation>
Szkic 4: Dwa rozdzielone pierścienie zewnętrzne

Dwa rozdzielone pierścienie zewnętrzne i wiele linii tworzących pierścień

Możliwość łączenia poszczególnych odcinków w pierścień nie jest ograniczona do pierścieni zewnętrznych, może być również stosowana do wewnętrznych pierścieni:
<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>
Szkic 5: Dwa rozdzielone pierścienie zewnętrzne i wiele linii tworzących pierścień

Złożona kombinacja wszystkich zaawansowanych możliwości

Ten przykład pokazuje złożoną kombinację wszystkich zaawansowanych funkcji: trzy zewnętrzne pierścienie, z których dwa mają jeden lub więcej pierścieni wewnętrznych, a wiele z nich składa się z więcej niż jeden linii.
<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>
Szkic 6: Złożona kombinacja wszystkich zaawansowanych możliwości

Wyspa w otworze

Korzystając z możliwości posiadania wielu pierścieni zewnętrznych w jednej relacji, wynika również, że można łatwo modelować "wyspy" w otworze:
<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>

Taki szkic jak ten, wymagał wcześniej różnych relacji "multipolygon", jeden z "way 1" jako zewnętrzną i "way 2" jako wewnętrzną, a także jedną z "way 2" jest zewnętrzną i "way 3" jako wewnętrzną. Takie kaskadowe ujęcie jest nadal potrzebne, gdy "wyspa" jest w środku czegoś innego niż obszar na zewnątrz, ale gdzie "wyspa" jest tym samym środowiskiem który może być otworem w otworze.

Szkic 7: Wyspa w otworze

Stykające się pierścienie wewnętrzne

Stykające się pierścienie dowolnego rodzaju powinny być wyrysowane closed ways (linią zamkniętą), jeśli w ogóle, w przeciwnym wypadku są bardzo trudne do obróbki przez klientów oprogramowania. Tak więc way #2 i way #3 powinien być jako linie zamknięte. Jeśli to możliwe, nalepiej jest połączyć je w jedną linię łamaną, jeśli reprezentują one tę samą funkcję.

Niektórzy maperzy używają bieżącej relacji "multipolygon" do łączenia stykających się pierścieni wewnętrznych:
<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>

Wdrażenie zaawansowanych wielokątów powinno próbować uczynić je tak, jakby stykające się pierścienie były rzeczywiście jednym pierścieniem. To jest jedyny przypadek, w którym wykorzystanie w OpenStreetMap odbiega od standardowych OGC Simple Features. W Simple Features, stykające się pierścienie wewnętrzne nie są obsługiwane, ponieważ są one zbędne (po co dwa pierścienie wewnętrzne kiedy można je połączyć w jeden).
W OpenStreetMap, czasami ma sens jeśli oznaczamy je indywidualnie, na przykład las z otwarciem, które jest w połowie zajęte przez jezioro a w połowie przez użytki rolne - można wtedy mieć również dwie "dziury" w lesie, jedną oznaczoną jako natural=water a drugą jako landuse=farmland. Jest to bardzo wygodny skrót.
Wymaganie od mapera stworzenia tylko jednej dziury w lesie, a następnie tworzenie indywidualnych wielokątów dla jeziora i pola uprawnego, byłoby zbyt dużo pracy dla niego.

Unikajmy "building multipolygon", w którym wewnętrzny pierścień dotyka zewnętrznego pierścienia.

Szkic 8: Stykające się pierścienie wewnętrzne

Nieprawidłowe przykłady

Przykłady nieprawidłowych relacji "multipolygon" aby zilustrować to, co nie powinno być robione.

Niezamknięte wielokąty

To jest przykład nieważnego wielokąta kiedy "way #2" i "way #3" nie jest połączone.
Szkic 9: Nieprawidłowe, niezamknięte wielokąty

Nakładające się na siebie, niezamknięte odcinki należące do tej samej roli

To jest przykład' nieważnego wielokąta kiedy punkty końcowe "way #2" i "way #3" mają wspólne więcej niż dwie linie.

This is an example of an invalid multipolygon as way #2 and way #3 endpoints share more than two ways.

Szkic 9: Nakładające się na siebie, niezamknięte odcinki należące do tej samej roli

Więcej przykładów

Oznaczanie

  • It is suggested to apply all tags which describe the area to the relation, and not to the ways. In many cases this may result in completely untagged ways.
  • Implementation for compatibility:
    • Drawing style is taken from the tagging of the relation itself.
    • If relation is not tagged, the drawing style of outer ways is used.
    • If the outer styles mismatch or no style is found it is considered an error.
    • Inner tagging leads to inner drawing. If inner tagging style equals outer style (an old method) the inner style should be handled as empty.

Szczegółowe oznaczanie

This section is for software developers, users should add tags always to relation and not to outer ways!

The tagging for this multipolygon relation can be done in quite a few ways. Here is a list of cases, problems and proposed solutions:

  • There is more than one outer way:
    The relation has tags
    Use the relation tagging. Ignore anything on the ways.
    The relation has no tags, but one or more constituting outer ways have an identical set of tags
    Valid data, take the tags from the tagged segments and apply them to the complete outer way.
    The relation has no tags, and constituting outer ways are tagged differently
    This is a problem situation with undefined results.
  • There is more than one inner way:
    One closed way (consisting of one or more segments) has no tags but another one has tags.
    The way without tags is rendered as a hole, the way with tags according to its tags.
    Different closed ways with different tags.
    Each hole is rendered on its own according to its tags.
    One closed way (consisting of two or more segments) where the segments have different tags.
    If some segments have no tags at all just use the tags from the other segments. If the segments have different behaviour is undefined (as for "outer" ways).

Rendering

  • JOSM is able to render these advanced multipolygons since revision 1203
  • Osmarender (T@H) supports advanced multipolygons
  • The mapnik rendering configuration at www.openstreetmap.org does not fully support "advanced multipolygons" (But mostly)
  • Fully supported by mkgmap since revision 1497
  • [GpsMid] supports at least a great majority of advanced multipolygon features
  • There is a suggested Algorithm for processing multipolygons.


Style mapowania, najlepsze sposoby

Multipolygons open up the possibility to create geometrically identical objects in different styles: as ways or as multipolygons, using closed or open ways, or with shared or unshared ways.

This raises the question of which mapping style to use. Some styles have advantages over others, and should be regarded as good practice. For others, the choice is more of a matter of preference, or whether one is an experienced or an inexperienced mapper.

Most generally when large areas share the same tag, they can be represented either by a large number of small multipolygons or closed ways, or by a smaller number of large multipolygons. For multipolygons themselves, two possible mapping styles are:

Metoda A
Wewnętrzne i zewnętrzne pierścienie tworzone są z linii zamkniętych o ile to możliwe, za wyjątkiem gdy te linie stają się bardzo duże (rzędu 2000 węzłów). Linie nie są zwykle wspólne dla różnych wielokątów
Metoda B
Każdy granica między dwoma wielokątami jest reprezentowana przez unikalną linię która jest następnie wspólna dla sąsiadujących wielokątów. W związku z tym pierścienie często składają się z kilku osobnych odcinków

The question of best practice for multipolygons has been discussed intensively over the years, see Talk:Relation:multipolygon and the forums. A final consensus hasn't emerged yet, but the following observations apply:

  • Mapping simple closed areas as multipolygons instead of ways increases the number of database objects and increases rendering time. This additional overhead of complexity should be avoided.
  • Sharing way segments between multipolygons (method B) offers a representational efficiency by avoiding redundant representations of overlapping ways.
  • Multipolygons consisting of non-closed ways (method B) are harder to handle by inexperienced users, and simple editors such as Potlatch 2. This has often led to the accidental destruction of such multipolygons by unsuspecting users.
  • Many experienced users have expressed their discomfort with method B, especially when the multipolygons are very large.
  • Huge multipolygons cause a slowdown of the rendering process.
  • Editing complex geometries in JOSM is easier, faster and less error-prone with method A. This is because method B requires deletion, creation and insertion of several way segments into the correct multipolygon relations.

So far there are no official restrictions on how to use multipolygons as long as they are geometrically valid. However adopting a considerate mapping style will help to keep the database clean and keep editing easy for every user.

Przykłady z Potlatch

Here's a grassy area within some woodland:
Potlatch 2 Multipolygon example - before

Click on the outer way:
Potlatch 2 Multipolygon example - after clicking on outer

Control-Click on the inner way:
Potlatch 2 Multipolygon example - after control-clicking on inner

Note how a "doughnut" icon has now appeared in the toolbox:
Potlatch 2 Multipolygon example - doughnut icon appears

Click it:
Potlatch 2 Multipolygon example - click doughnut

To see the actual tags that have been added, click advanced:
Potlatch 2 Multipolygon example - click advanced

The multipolygon has been created:
Potlatch 2 Multipolygon example - multipolygon

Przykłady z Potlatch 1

Potlatch 1 example

In Potlatch 1, roles for a multipolygon relation should be assigned to the relation member itself, and not as separate tags. When in edit mode, select the relation member and put inner or outer in the box on the same line as where it says multipolygon.

Zobacz też