Ko:Relation:multipolygon

다중다각형 (multipolygon) 유형의 관계는 복잡한 형태의 영역 (다각형)을 표현할 때 사용하는 것으로, 안쪽에 구멍이 나 있거나 각 부분이 여러 개로 분리된 형태일 경우에 주로 유용합니다. 또한 길 (way)을 중복해서 그리지 않고도, 선형 객체 (자체 속성을 지닌 테두리나 경계, 도로 등)와 그 안의 영역 (다중다각형 관계로 태그된 형상)을 구분하는 데에도 유용합니다.

오픈스트리트맵 (OSM)에서 일반 영역은 닫힌 길을 생성하고, 선이 아닌 영역을 나타내는 태그를 지정하는 식으로 표현합니다. 예를 들어 landuse=forest (숲지대) 태그가 지정된 길은 영역으로 인식되지만, highway=trunk (고속화도로)가 태그된 길은 영역으로 인식되지 않습니다. 그러나 이런 방식은 윤곽선이 하나의 길로만 구성되고 안에 구멍이 뚫려 있지 않은 영역에만 적용됩니다. 그보다 복잡한 형태의 경우, 예를 들어 윤곽선이 여러 개의 길로 나뉜 경우, 영역이 여러 개의 부분으로 분리되어 있는 경우, 또는 구멍이 있는 경우에는 다중다각형을 사용해야 합니다.

다중다각형 관계는 외곽선을 이루는 각각의 길을 선택해 outer (외선) 역할로, 내곽선을 이루는 길을 inner (내선) 역할로 지정하여 만들 수 있습니다. 길의 갯수에는 제약이 없지만, 다중다각형의 형태를 구성하기 위해 각 윤곽선의 길이 어떤 방식으로든 하나의 띠로 연결되어 있어야 합니다.

On tag description pages, multipolygons are treated as areas rather than relations , since the same tags apply to both closed ways and multipolygons. See FAQ.

편집 방법

iD 편집기

iD 편집기에서는 한 영역과 내부 영역을 선택한 뒤 '병합' 기능으로 다중다각형을 만들 수 있습니다.

iD 편집기에서 다중다각형을 자동 생성하는 방법['펼치기'로 내용 확인]

작은 섬이 들어가 있는 호수를 매핑해 봅시다.

먼저 영역을 클릭하고 지물의 외곽을 따라 선을 긋습니다.

호수(lake)라고 태그합니다.

호수의 내곽을 따라 영역을 만들고 적당한 태그를 지정합니다. 이 경우에는 '작은 섬' (islet)을 태그합니다.

Shift 키를 누른 상태에서 두 영역을 클릭해 동시에 선택한 다음, 두 영역 중 하나를 마우스 오른쪽 버튼으로 클릭하여 편집 메뉴를 열고 '병합' 작업을 선택합니다. 아니면 두 영역을 동시에 선택한 뒤 단축키 'C'를 눌러 '병합' 작업을 할 수도 있습니다.

iD에서 관계를 수동으로 생성하는 예제['펼치기'로 내용 확인]

구멍이 뚫린 건물을 지도에 표현해 봅시다.

지물의 외곽 경계선을 따라 선을 긋습니다.

지물을 이루지 않고 있는 내부 경계선을 따라 선이나 영역을 긋습니다.

Shift 키를 누른 상태에서 지물의 내외곽 요소를 동시에 선택합니다.

요소를 선택한 상태에서 사이드바 하단의 '관계 추가' 버튼을 클릭합니다.

'부모 관계 선택'이라 쓰인 입력란을 클릭하고 펼쳐진 메뉴에서 '새 관계...'를 클릭합니다.

지물 목록에서 '다중 다각형'을 클릭합니다.

다중 다각형의 지물 유형을 선택합니다.

지물 메뉴의 문제 알림창을 확인하고 각각의 선을 'inner'(내선)이나 'outer'(외선)으로 역할을 설정하여 문제를 해결합니다.

마우스 커서를 각 문제에 올려놓으면 iD 편집기 상에서 어떤 요소의 문제를 가리키는지 확인할 수 있습니다. 해당 요소는 파란색으로 강조 표시되며, 이를 통해 다중 다각형의 외곽선인지 내곽선인지를 구분할 수 있습니다.

아래의 상황에서 포인터를 첫번째 문제에 두고 있고, 파란색으로 표시된 것이 건물의 외곽선에 해당하므로 '외선으로 설정'을 클릭하여 외곽선으로 두어야 합니다.

아래의 모습이 되었다면 지금 선택한 지물은 완벽한 다중 다각형 관계가 된 것입니다. 지물에 태그가 달려 있고, 'outer' 역할로 설정된 구성원이 한 개 이상 있으며, 'inner' 역할을 가진 구성원도 한 개 이상 있으며, 문제 알림창이 뜨지 않다는 점으로 확인이 가능합니다.

내곽선을 이루는 요소(선 / 영역) 가운데 다른 지물을 나타내는 경우가 있다면, 해당 요소를 선택하여 지물의 종류를 바꿀 수 있습니다. 그러나 외곽선은 항상 선으로 유지되어야 합니다.

아래의 예시에서는 내곽선을 이루는 영역이 안뜰 공간으로 설정된 모습입니다.

이상의 예시는 오픈스트리트맵에서 실제로 확인할 수 있습니다.

JOSM

[메뉴]-[도구]-[다중 다각형 생성]을 클릭하거나 Ctrl+B 단축키로 만들 수 있습니다.

JOSM에서 다른 객체 안의 섬을 표현하는 예제 ['펼치기'로 내용 확인]

가운데에 연못을 둔 습지를 표현해 봅시다.

• 
  현장의 항공 사진을 불러와 확인합니다.
• 
  연못의 윤곽선을 그리고 태그를 달아 줍니다.
• 
  주변 습지의 윤곽선을 그리되 태그는 달지 않습니다.
• 
  양쪽 객체를 모두 선택해 줍니다.
• 
  Ctrl+B를 누르거나 메뉴-도구-다중 다각형 생성을 클릭한 뒤 습지로 태그를 붙여 줍니다.

참고: 이미 그려져 있는 길을 활용하는 경우, 외곽을 이루는 길과 내곽을 이루는 길을 다중 다각형으로 합친 뒤에도 외곽의 길에 달린 태그는 그대로 유지되므로 속성에서 제거해 주어야 합니다. 과거 버전의 JOSM 편집기일 경우 이를 검사하고 업로드 전에 경고 메시지를 표시합니다. 최신 버전에서는 이 단계를 자동으로 수행합니다.

JOSM에서 내부 고리가 서로 맞닿은 지물을 만드는 예제 ['펼치기'로 내용 확인]

내부의 습지가 서로 맞닿아 있는 숲을 만들어 봅시다.

• 
  두 번째 습지의 윤곽선을 그리고, 습지 태그를 달아줍니다.
• 
  두 습지와 주변의 숲을 모두 선택합니다.
• 
  이것도 다중 다각형으로 만들고 태그를 달아 줍니다.
• 
  렌더러 입장에서 이 관계가 무슨 의미를 지닌 건지 추정할 필요가 없습니다.

주의: 이렇게 생성된 다중 다각형은 OGC 규격을 준수하지 않습니다. 자세한 사항은 아래를 참조해 주세요.

JOSM에서 OGC 규격을 준수하며 내부 고리가 맞닿은 예제 ['펼치기'로 내용 확인]

OGC 규격에서는 내부 고리끼리 구분시키는 경계선을 외곽 다중 다각형의 일부로 삼는 것을 허용하지 않고 있습니다. 이러한 경우 습지를 단순히 합치는 것이 아니라, 길(way)를 하나 더 그어야 합니다.

• 
  두 내부 영역의 외곽선을 새 길로 따라 그리고 태그는 달지 않습니다. 이렇게 만든 길과 주변의 길을 새로 생성된 다중 다각형의 구성원으로 선택합니다.

참고: OGC 규격을 준수하는 다중 다각형을 생성하는 또다른 방법은 내부 다각형의 외곽선을 분할하여, 중간의 분리선만 제외하고 외부 다각형과의 접촉 부분만 결합하는 것입니다.

Vespucci

• https://community.openstreetmap.org/t/how-to-make-a-multipolygon-in-vespucci/8606/2

태그

태그	입력값	설명
type	multipolygon	애플리케이션에 본 관계의 구성원을 대상으로 영역 생성 규칙을 적용하도록 지시합니다.
boundary	*	사용하지 마세요. type=boundary를 대신 사용하세요 (사용 방법은 비슷하지만 비선형 요소를 특정 역할로 추가할 수 있는 유형입니다).
natural	*	해당 영역을 나타내는 지물의 종류(자연, 토지이용, 건물, 인공 구조물, 편의 시설, 레저 시설, 보행자 구역, 수변 지역 등)를 설명하는 태그가 하나 이상 달려 있어야 합니다. 이 태그는 대부분 상호배타적 태그로서, 다른 종류 태그와 중복으로 쓸 수 없습니다. 종류 태그를 또 추가하면 관계를 해석할 때 상충되기 때문입니다. 필요하다면 별도의 다중다각형을 사용하세요. '하나의 지물에는 하나의 요소'가 일반적인 규칙입니다.
landuse	*
building	*
man_made	*
amenity	*
leisure	*
highway	pedestrian
waterway	*
...	...
layer	*	정보 속성 (지물의 하위 유형, 레이어, 명칭, 출처, 메모 등)과 관련해 선택적으로 쓸 수 있는 추가 태그입니다. 여기에 해당되는 태그는 일반 영역(Area)에서의 쓰임새와 동일한 방식으로 사용하면 됩니다.
name	*
note	*
...	...

구성원

길/마디	역할	개수	설명
	outer	1개 이상	해당 영역의 윤곽을 드러내는 데 필요한 외부 고리를 이루는 길(way)에 부여합니다. 딱 하나의 닫힌 길만 추가해도 됩니다.
	inner	0개 이상	해당 영역에 구멍의 형태가 나 있어 필요한 경우에 한하여, 내곽 고리를 이루는 길(way)에 부여합니다. 이 때 영역 내부에 완전히 들어가 있어야 합니다. 딱 하나의 닫힌 길만 추가해도 됩니다.
	(없음)	0개	사용하지 마세요. 더 이상 이렇게 쓰지 않습니다. 역할을 공란으로 비워두면 각 툴에서 잘못 처리하거나, 각 길이 이루는 형상으로부터 실제 역할을 추정하는 과정에서 느리고 복잡한 알고리즘이 적용되다 실패하는 상황으로 이어질 수 있습니다.
	-	0개	사용하지 마세요.
	-	0개	사용하지 마세요.

사용법

다중다각형을 사용할 때에는 다음의 의도에 따라야 합니다.

• 다중다각형을 묘사하는 태그 (예: landuse=forest)는 항상 관계에 추가해야 합니다. 외곽선으로 지정된 길은 그 자체로 어떤 실체로 존재하는 경우가 아니라면 반드시 미태그 상태로 남겨두어야 합니다. 일례로 네 개의 울타리로 숲이 둘러 쌓여 있는 경우, 네 개의 길은 barrier 태그를 적용하더라도 숲 관계의 'outer' 역할로 지정할 수는 있습니다. 그러나 숲 관계에 지정된 외곽선이 별다른 실체를 지니지 않고 있다면, 태그가 달리지 않은 상태의 길로 남겨두어야 한다는 뜻입니다.
• 반대로 내곽선으로 지정된 길이 실체를 지니고 있다면 (예: 숲 한가운데에 연못으로 된 구멍이 난 경우), 그 길에는 반드시 그 실체를 나타내는 태그가 달려 있어야 합니다.
• 그렇지 않은 경우에는 태그가 달리지 않은 상태로 남겨두어야 합니다.
• 길의 방향은 상관 없습니다.
• 관계 구성원의 순서도 상관 없습니다 (다만 구성원 목록을 올바르게 정렬하면 다른 편집자들이 제대로 된 상태인지 확인하고 문제를 발견하는 데 도움이 될 수 있습니다).

과거에는 독일 지역을 중심으로 경계 관계에 대해 type=boundary가 아닌 이 type=multipolygon 을 주로 사용해 왔습니다. 그러나 이러한 편집 방식은 널리 받아들여지지 못했으며 더 이상 권장되지 않습니다.

다중 다각형의 올바른 상태

일반적으로 다중 다각형 관계가 사용되는 다중 다각형은 OGC 단순 지물 표준을 준수하도록 되어 있습니다. 이 기준에서 벗어나는 다중다각형(예: 고리가 교차하는 다각형 등)이라면 잘못된 다중다각형으로 인식되어야 합니다. 단 아래의 경우처럼 내부의 고리가 서로 접촉하는 경우는 예외로 하고 있습니다.

끝점을 연결했을 때 닫힌 다각형을 형성하는 길(way)의 부분집합을 올바른 다각형으로 정의합니다.

또한 첫번째 마디와 마지막 마디가 동일하지 않은 길이라면, 닫혀 있지 않은 길(way)로 정의합니다.

올바른 다중다각형 관계를 형성하기 위한 조건은 다음과 같습니다.

• 다중다각형 관계의 구성원으로 있는 길은 전체적으로 하나 이상의 닫힌 다각형을 이룰 수 있어야 합니다. 관계에 속하는 길을 모두 합쳤다면 하나 이상의 닫힌 고리를 이루어야 합니다. 다각형의 정의
• 하나의 끝점을 공유하는, 닫혀 있지 않은 길의 개수는 정확히 두 개여야 하며, 개수가 그 이상이어서는 안 됩니다. 다시 말해 아래의 그림 예시에서 하나의 검은 점에 연결된 선이 2개 이상이어서는 안 된다는 뜻입니다.
  • 끝점을 공유하고 있는 길이 1개뿐일 경우, 다각형은 닫힐 수 없으며 잘못된 형태가 됩니다. 잘못된 예시 1
  • 끝점을 공유하고 있는 길이 3개 이상일 경우, 닫힌 다각형이 무엇인지를 명확히 판별할 수 없어 잘못된 형태가 됩니다. 잘못된 예시 2 (단, 여러 개의 내부 고리가 서로 붙어 있는 경우에는 하나의 끝점에 짝수 개의 길이 공유하고 있을 수도 있으며 이 경우는 허용됩니다)
• 내부의 다각형은 외부 다각형을 침범해서는 안 되며, 공통 선분으로 닿아서도 안 됩니다 (위에서 설명한 것처럼 고립된 마디의 경우에는 예외). 다각형의 형태를 변경해 주면 서로 겹칠 위험을 완전히 방지할 수 있습니다.

XML 예제

외곽선과 내곽선이 하나씩 있는 경우

가장 간단하면서도 제일 많이 사용되는 예제로, 하나짜리로 닫혀 있는 길로 외곽선과 내곽선을 하나씩 두고 있는 다중다각형입니다. <relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" ref="1" role="outer" /> <member type="way" ref="2" role="inner" /> </relation>

그림 1: 외곽선과 내곽선이 하나씩 있음

실제 지물의 태그 예시

위의 형상이 숲 속의 연못을 나타낸다고 가정해 보겠습니다. 이러한 지형지물에 태그를 지정하는 방법은 다음의 두 가지가 있습니다.

<relation id="1"> <tag k="type" v="multipolygon"/> <member type="way" ref="1" role="outer"/> <member type="way" ref="2" role="inner"/> </relation> <way id="1"> <tag k="natural" v="forest"/> <tag k="name" v="Grey Wood"/> <nd ref="101"/><nd ref="102"/><nd ref="103"/> <nd ref="104"/><nd ref="105"/><nd ref="101"/> </way> <way id="2"> <tag k="natural" v="water"/> <tag k="water" v="pond"/> <tag k="name" v="Whitewater"/> <nd ref="201"/><nd ref="202"/><nd ref="203"/> <nd ref="204"/><nd ref="201"/> </way> 위의 태그는 잘못된 예시입니다.다중다각형은 기하학적 표면만 나타낼 뿐 지물은 표현하지 않고 있으며, 1번 길로 정의된 숲 표면이 2번 길로 정의된 연못을 완전히 덮어 버리게 됩니다. 렌더링 프로그램이나 애플리케이션은 이렇게 태그된 지물을 제대로 처리하지 못하며, 연못이 정확하게 그려지고 채워졌더라도 숲 영역에 완전히 가려져 보이지 않게 됩니다.

<relation id="1"> <tag k="type" v="multipolygon"/> <tag k="natural" v="forest"/> <tag k="name" v="Grey Wood"/> <member type="way" ref="1" role="outer"/> <member type="way" ref="2" role="inner"/> </relation> <way id="1"> <nd ref="101"/><nd ref="102"/><nd ref="103"/> <nd ref="104"/><nd ref="105"/><nd ref="101"/> </way> <way id="2"> <tag k="natural" v="water"/> <tag k="water" v="pond"/> <tag k="name" v="Whitewater"/> <nd ref="201"/><nd ref="202"/><nd ref="203"/> <nd ref="204"/><nd ref="201"/> </way> This is correct (much better): the forest tags are transferred from the outer way to the multipolygon, the forest no longer overlaps the inner pond in way #2, which keeps its own tags, and the inner way #1 itself is left without any tag (it does not represent the forest or any feature, it's used only here for defining the complete geometry of the multipolygon). Ways without any tag are valid in OSM when they are referenced as members of one or more relations.

외곽선이 한 개, 내곽선이 두 개 있는 경우

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

그림 2: 외곽선이 한 개, 내곽선이 두 개 있음

여러 개의 길이 고리를 이룬 경우

The multipolygon schema allows any inner or outer ring to consist of more than one way. This is useful for multipolygons encompassing very large areas, where it would be impractical to have one way run around the whole of it: <relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" ref="1" role="outer" /> <member type="way" ref="2" role="outer" /> <member type="way" ref="3" role="inner" /> </relation>

Figure 3: Multiple ways forming a ring

두 개의 외곽선이 동떨어진 경우

Unlike simple multipolygons, the multipolygon relation allows any number of outer rings and thus is a true multipolygon: <relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" ref="1" role="outer" /> <member type="way" ref="2" role="outer" /> </relation>

Figure 4: Two disjunct outer rings

두 개의 외곽선이 동떨어진 경우 + 여러 개의 길이 고리를 이룬 경우

The ability to combine a ring from individual ways is not limited to outer rings, it can also be used for inner rings: <relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" ref="1" role="outer" /> <member type="way" ref="2" role="inner" /> <member type="way" ref="3" role="inner" /> <member type="way" ref="4" role="outer" /> <member type="way" ref="5" role="inner" /> </relation>

Figure 5: Two disjunct outer rings and multiple ways forming a ring

총집합

This example shows a complex combination of all features: three outer rings, two of which have one or more inner rings, and plenty of them consisting of more than one way. <relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" ref="1" role="outer" /> <member type="way" ref="2" role="outer" /> <member type="way" ref="3" role="outer" /> <member type="way" ref="4" role="outer" /> <member type="way" ref="5" role="inner" /> <member type="way" ref="6" role="inner" /> <member type="way" ref="7" role="inner" /> <member type="way" ref="8" role="inner" /> <member type="way" ref="9" role="inner" /> <member type="way" ref="10" role="inner" /> <member type="way" ref="11" role="inner" /> <member type="way" ref="12" role="outer" /> <member type="way" ref="13" role="outer" /> <member type="way" ref="14" role="outer" /> <member type="way" ref="15" role="outer" /> <member type="way" ref="16" role="inner" /> <member type="way" ref="17" role="inner" /> <member type="way" ref="18" role="inner" /> <member type="way" ref="19" role="inner" /> <member type="way" ref="20" role="outer" /> </relation>

Figure 6: Complex combination of all features

구멍 안에 섬이 있는 경우

From the possibility of having multiple outer rings in one relation, it also follows that you can easily model "islands" within a hole: <relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" ref="1" role="outer" /> <member type="way" ref="2" role="inner" /> <member type="way" ref="3" role="outer" /> </relation> A construct like this would previously have required different multipolygon relations, one with way 1 being outer and way 2 being inner, as well as one with way 2 being outer and way 3 being inner. Such cascading is still needed when the "island" in the middle is something else than the area on the outside, but where the "island" is the same stuff it can just be made a hole in the hole. Beware though, that following this method, still a dual determination of the area mapped by way 3 will be created, as the hole and the island DO overlap!

Figure 7: Island within a hole

내부 고리가 붙어 있는 경우

Some mappers use the current "multipolygon" relation for combining touching inner rings: <relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" ref="1" role="outer" /> <member type="way" ref="2" role="inner" /> <member type="way" ref="3" role="inner" /> </relation> An implementation of multipolygons should attempt to render these as if the touching rings were indeed one ring. This is the one case where OpenStreetMap use deviates from standard OGC Simple Features. In Simple Features, touching inner rings are not supported because they are unnecessary (why make two inner rings when you could combine them into one). In OpenStreetMap, they sometimes make sense if tagged individually, for example a forest with a clearing which is half occupied by a lake and half by farmland - you would have two "holes" in the forest, one being tagged as natural=water and the other as landuse=farmland. This is a convenience shortcut; requiring of mappers to create only one hole in the forest, and then create individual polygons for lake and farmland, saving a step. Avoid building multipolygons where an inner ring touches an outer ring though. There is some discussion about this section on the talk page.

Figure 8: Touching inner rings

잘못된 예시

다음은 잘못된 다중다각형 관계의 몇 가지 사례입니다. 이렇게 해서는 안 된다는 점을 기억해 주세요.

다각형이 닫혀 있지 않은 경우

2번 길과 3번 길이 연결되지 않아 잘못된 다중다각형으로 판정된 예시입니다.

그림 9: 닫혀 있지 않아 잘못된 다각형

중첩되거나 닫혀 있지 않는 구성원의 길이 같은 역할에 속해 있는 경우

2번 길과 3번 길의 두 끝점이 두 개 이상의 길을 공유하고 있어 잘못된 다중다각형으로 판정된 예시입니다.

Figure 10: invalid ambiguous multipolygon relation

단 하나의 다각형으로 생성된 다중 다각형

4번과 5번 마디가 10번과 11번 미다로 재사용되어 잘못된 다중다각형으로 판정되는 예시입니다. Open Geospatial Consortium’s (OGC)의 OpenGIS 수칙에서 유효한 다각형이 아님을 규정하고 있습니다. Osmose 품질 검증 도구에서도 오류 메시지를 띄우게 됩니다.

그림 11: 모호한 외곽선을 사용해서 잘못된 다중다각형 관계

더 많은 예시

• 유효한 다중다각형의 예시는 Multipolygon Examples 페이지에서 더 많이 만나보실 수 있습니다.
• Proposition for examples of valid and invalid unusual configuration

추가 정보

• The drawing style is always taken from the tagging of the relation itself.
• Drawing of inner areas is handled independent from multipolygon - inner ways can form closed rings with area tags or also be outer ways of multipolygons.
• Area styles containing drawing rules for their boundaries can lead to conflicts - An inner way may have a line style (e.g. fence) an own area style (e.g. water) and an multipolygon area style (e.g. forest). Each software may define drawing order different, but a general rule may be to give line style highest priority and multipolygon area style for inner ways the lowest priority.
• There is a suggested algorithm for processing multipolygons.

• Note that before May 2017, some multipolygons also had their tags on the outer way (if there was only one such way or all ways had the same tags) while keeping the respective multipolygon-relation untagged. But when consuming older OSM data excerpts, it is necessary to handle such old style multipolygons, too. See old style multipolygons for historic notes.

편집 방식 (최선의 실천)

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:

Method A

Inner and outer rings are created from closed ways whenever possible, except when these ways become very large (on the order of 2000 nodes). Ways are usually not shared by different multipolygons

Method B

Every border between two multipolygons is represented by a unique way which is then shared by the adjacent multipolygons. Consequently the multipolygon rings are often composed of several open ways

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.

도움이 되는 도구

• Relation Check
• OSM Inspector has support for multipolygon checks as part of the "Areas" view

잘못된 태그 사례

type=polygon

		$1%
		$1%
		$1%
		$1%

More details at taginfo

• type=polygon🔎

만약 이 태그가 쓰인 곳을 알고 있다면, 다른 태그로 대체할 수 있는지 확인해 주세요.
자신이 정확히 뭘 하고 있는지 알지 못하면서 무작정 수정하면 안 됩니다!

type=area

		$1%
		$1%
		$1%
		$1%

More details at taginfo

• type=area

만약 이 태그가 쓰인 곳을 알고 있다면, 다른 태그로 대체할 수 있는지 확인해 주세요.
자신이 정확히 뭘 하고 있는지 알지 못하면서 무작정 수정하면 안 됩니다!

type=way

		$1%
		$1%
		$1%
		$1%

More details at taginfo

• type=way🔎

만약 이 태그가 쓰인 곳을 알고 있다면, 다른 태그로 대체할 수 있는지 확인해 주세요.
자신이 정확히 뭘 하고 있는지 알지 못하면서 무작정 수정하면 안 됩니다!

role=outer

		$1%
		$1%
		$1%
		$1%

More details at taginfo

• role=outer🔎

만약 이 태그가 쓰인 곳을 알고 있다면, 다른 태그로 대체할 수 있는지 확인해 주세요.
자신이 정확히 뭘 하고 있는지 알지 못하면서 무작정 수정하면 안 됩니다!

role=inner

		$1%
		$1%
		$1%
		$1%

More details at taginfo

• role=inner🔎

만약 이 태그가 쓰인 곳을 알고 있다면, 다른 태그로 대체할 수 있는지 확인해 주세요.
자신이 정확히 뭘 하고 있는지 알지 못하면서 무작정 수정하면 안 됩니다!

같이 보기

• Relation:multipolygon/validity
• See The Future of Areas for some discussions on how to improve area handling in OSM.
• Relation:multilinestring