Ko:Relation:boundary

boundary=* (경계) 관계는 정치(영토 등), 행정, 자연보호 등의 목적으로 사용되는 경계를 정의하는 데 사용됩니다. 경계 관계는 다중 다각형과 유사한 정의를 따르고 있습니다. 즉 경계 관계는 최소 1개 이상의 외부 경계선을 갖추어야 하며, 월경지나 위요지는 부가 경계선을 사용하여 정의한다는 뜻입니다.

관계로 표현되는 경계는 위상적, 논리적인 면에서 서로 중복될 수 있습니다. 예를 들어, 한 국가의 주(州)는 국가의 국경을 일부 공유하고, 다른 주와도 서로 간의 경계를 공유합니다. 따라서 하나의 경계선은 여러 경계 관계(예: 국가, 주, 시군구, 기초자치단체)에 동시에 묶일 수 있습니다. 이러한 접근 방식을 통해 경계의 모든 부분을 쉽게 연결하고 중복된 경계선이 여러 개 생성되는 것을 방지할 수 있습니다.

일부 경계는 강과 같은 실제 지형지물에 명확하게 표시되거나 그것을 따르고 있어 실체를 확인할 수 있지만, 현장에서 검증할 수 없는 경계도 많으므로 외부 출처에서 가져와야 하는 경우가 많습니다. 그러나 경계를 숲이나 강과 같은 실제 지형지물에 직접 연결하거나 이러한 지형지물의 흔적을 경계로 재사용하는 것은 피해야 합니다 (하나의 지형지물에는 하나나 요소만 사용하기). 이러한 지형지물은 시간이 지남에 따라 현실에서 변화하고 오픈스트리트맵에서도 업데이트되지만, 일반적으로 경계의 형태는 그대로 유지되기 떄문입니다. 단, 법령 등으로 경계 자체가 해당 ​​지형지물로 정의된 경우에는 예외적으로 허용될 수 있습니다.

태그 방법

경계 영역이 렌더링되는 근거 요소는 관계와 개별적인 닫힌 길 모두가 될 수 있습니다. 이 때 관계를 사용하면 더 나은 라벨링(이름 표시)처럼 어떠한 경우에서든 전체적인 객체로서의 처리가 가능해집니다.

경계형 길에는 boundary=administrative과 admin_level=* 태그를 붙일 수 있으며 후자의 경우 그 경계를 윤곽선으로 삼는 최상위 단계의 행정구역을 입력값으로 삼습니다 (국가, 시도, 시군구가 걸려 있다면 admin_level은 국가에 해당되는 2로 입력합니다). source=* 태그는 항상 넣을 것을 권장합니다. 다만 데이터 소비자의 입장에서 선에 걸려 있는 관계로 정보를 추론할 수 있으므로 이런 태그는 선택 사항입니다. 그렇기 때문에 경계선은 다중다각형과 마찬가지로 전혀 태그되지 않은 상태로 둘 수 있습니다.

과거에는 경계형 길에 name:left=*, name:right=*, nation:right=*, region:right=* 등의 태그를 추가하여 경계선 좌우측으로 맞닿은 행정구역을 정의하기도 했습니다. 하지만 이런 태그 방식은 편집하기가 번거롭고 오류 발생 가능성이 높으므로, 현재는 국가와 시도, 시군구별로 관계를 설정하는 방식으로 대체되었습니다. 따라서 길에 달려 있는 name:left=*/name:right=* 등의 태그는 제거하여도 무방합니다.

관계 자체의 태그

키	입력값	설명
type	boundary	type=multipolygon is also used, but deprecated for boundary relations (see software support).
boundary	administrative	For an administrative boundary (sometimes in the middle of a river or 12 miles away from coastline). For other boundary types see boundary=*
name	(이름)
admin_level	(행정구역 단계). an integer with value between 2 and 10, and country-specific meaning.

관계 구성원

요소	역할	개수	설명
	outer	! 1+	Defines an outer boundary of this territory. All outer ways taken together must form one closed ring, or multiple rings in cases when the territory is discontiguous (for example, an archipelago). For unclosed linear borders, see Relations/Proposed/boundary segment.
	inner	? 0+	Defines an inner boundary of this territory, i.e., an enclave.
	<empty>	✗ 0	Deprecated, don't use. Use outer or inner instead. Some tools may treat it only as outer, others will attempt to guess it using complex geometry inference.
	admin_centre	? 0–1	Node representing the administrative centre (a capital, county seat etc.), usually a town, city or village (depending of the boundary level, see place=*). This role is for capitals (as in capital cities), not capitols (as in legislative buildings).
	label	? 0–1	Node representing the place, located at the coordinate where the place is typically labelled. Despite the name of this role, it is not a general mechanism for label placement hints; one can think of it as a "cultural centre" or "logical centre" for the boundary. When placing the node, consider where you would map the place as a point feature if the boundary were unknown or ill-defined. A city's commonly accepted "centre" may be at the city hall, a public square, or the origin of the city's street grid, rather than the geographic centroid of the boundary. For example, Chicago's node remains located in the central business district near the lakeshore, even though the city has expanded away from the lakeshore. This role may also be useful when there's an enclave or the boundary has a large concavity, and the default placement of the label in the centre of the bounding box would fall completely outside the boundary area. Note that different map styles require a different label placement (as different map styles display different objects, may use labels in different languages, labels may use a different style and it may be desirable to avoid blocking some objects with the label – for example, a standard map may prefer the label of a coastal town to be placed on the sea, a map displaying sea routes would prefer to place the town label inland). As a result, the placement of these nodes is optimized for specific map styles, making them a form of tagging for the renderer. The label-node could contain a place=* tag and using a key from the table administratively declared places (like place=country; place=state; place=county; etc.) if applicable. For example, see France.
	subarea	? 0+	Refer to relations of sublevel boundaries inside this administrative level. Optional, disputed, and redundant (references to sublevels may also be found with spatial queries, provided that there's no overlap between similar subdivisions). Also referencing other relations makes editing more complicated in some cases.

태그 예제

	<relation id="1"> <tag k="type" v="boundary" /> <tag k="boundary" v="administrative" /> <tag k="admin_level" v="2" /> <tag k="name" v="light green country A excluding C" /> <member type="way" id="AB" role="outer" /> <member type="way" id="AC" role="inner" /> </relation> <relation id="2"> <tag k="type" v="boundary" /> <tag k="boundary" v="administrative" /> <tag k="admin_level" v="2" /> <tag k="name" v="dark green country B also including C" /> <member type="way" id="AB" role="outer" /> <member type="way" id="AC" role="outer" /> </relation>
C는 A의 위요지이고 B의 월경지입니다.
	<relation id="1"> <tag k="type" v="boundary" /> <tag k="boundary" v="administrative" /> <tag k="admin_level" v="2" /> <tag k="name" v="light green country A" /> <member type="way" id="AB" role="outer" /> <member type="way" id="AC1" role="outer" /> <member type="way" id="AD" role="outer" /> <member type="way" id="AC2" role="outer" /> </relation> <relation id="2"> <tag k="type" v="boundary" /> <tag k="boundary" v="administrative" /> <tag k="admin_level" v="2" /> <tag k="name" v="dark green country B also including D" /> <member type="way" id="AB" role="outer" /> <member type="way" id="BC" role="outer" /> <member type="way" id="AD" role="outer" /> <member type="way" id="CD" role="outer" /> </relation> <relation id="3"> <tag k="type" v="boundary" /> <tag k="boundary" v="administrative" /> <tag k="admin_level" v="2" /> <tag k="name" v="purple country C" /> <member type="way" id="AC1" role="outer" /> <member type="way" id="CD" role="outer" /> <member type="way" id="AC2" role="outer" /> <member type="way" id="BC" role="outer" /> </relation>
D는 B의 월경지이지만, C와 경계를 맞닿고 있으므로 A의 위요지는 아닙니다.

• Baarle Nassau is a good use case for this relation. It has exclaves in enclaves. The exclaves in the enclaves of Belgium would just be added as exclaves to the relation of the Netherlands, the dutch province Noord-Brabant and the village border.
• There are more examples!

소프트웨어 지원

Software should support all deprecated types until they disappear in database:

• type=multipolygon as well as type=boundary (An administrative boundary can be definitively recognised through the existing boundary=* tag)
• empty role for outer (note blank role is obsolete for multipolygons as well, but usually defaults to outer)

The following data consumers make use of the label or admin_centre role in some manner:

Software package	label	admin_centre
CoMaps	Positioning the administrative area's label [1][2]
Cosmogony	Synchronizing multilingual name tags [3]
Freemap Slovakia WikiPois	N/A	Location of administrative area [4]
libpostal	[5]	[6]
Nominatim	Links place point and area metadata [7]	N/A
OpenHistoricalMap vector tiles	Positioning the administrative area's label [8]	N/A
OpenTopoMap	N/A	[9]
Organic Maps	Positioning the administrative area's label [10][11]
OsmAnd	Positioning the administrative area's label [12][13]
OSMNames	Deduplicating point and area representations of the same place. [14]
OSMPoliticalMap	N/A	[15]
Pelias pbf2json	N/A	Determining the administrative area's centroid [16]

Tools

• OSM Inspector
• Relation Analyzer
• Relation Check
• Relevant Sophox queries:
  • Boundaries that are subareas of more local boundaries
  • Boundary labels that are not nodes

Downloads

• OSM Boundaries by User wambacher