User:Skybunny/Relation:boundary

boundary=* relations are used for describing territorial boundaries, and marking enclaves/exclaves of them.

Relations are used rather than Areas in order to:

• Allow one OSM data structure per boundary
• Simplify associating all the components of a boundary with each other
• Allow the sharing of ways which may describe multiple boundaries (for example, when the same way represents both a nation's and a state's outer edge)

The most common use of boundary relations in OSM is in administrative boundaries, which describe political boundaries, and are indicated with the key value boundary=administrative. However, many other types exist, describing features like maritime bounds and national parks. See boundary=* for more information.

Boundary relation tags

Key	Value	Discussion
type	boundary	Required.
boundary	administrative	Optional. (One of boundary=administrative or boundary=administrative is required for administrative relations.) Administrative boundary way members may lie several miles away from land.
land_area	administrative	Optional. (One of boundary=administrative or boundary=administrative is required for administrative relations.) For coastlines and real boundaries on land.
name	A name	Required.
admin_level	The administrative level	Required for administrative boundaries.
type	multipolygon	Deprecated for boundary relations (see software implementation notes). When found, boundaries with this tag should be migrated to type=boundary and checked for consistency.

Notes

If you have a land-locked administrative area in the region you should set both: boundary=administrative and land_area=administrative. If the land_area is not the same as the boundary, make two relations, one with land_area=administrative and one with boundary=administrative.

Relation members

Element	Role	Occurrence	Discussion
	outer	! 1+	The multiple ways that form the closed border
	inner	? 0+	Enclaves of this border - the multiple ways that form the closed inner borders
	waypoint	? 0–1	Node representing the location a navigation user should be routed to, if they select a boundary relation as a navigation destination. Required if no other standalone node is a member of the boundary relation. Recommended if other standalone nodes do not fulfill this navigational purpose.
	admin_centre	? 0–1	Specific to administrative relations. A node representing the administrative centre (a capital, county seat etc.), usually a town, city or village (depending on the boundary level, see place=*).
	label	? 0–1	Node representing where to draw the label, for map renderers that choose to support it. (To name one, this is not supported by openstreetmap-carto rendering). May be useful when there's an enclave or the boundary has a large concavity, and the default placement of a label "in the center of the bounding box" would fall completely outside the boundary area.
	<empty>	✗ 0	Deprecated for boundary relations (see software implementation notes). Use the role outer instead.
	subarea	? 0+	Refer to relations of sublevel boundaries inside this administrative level. Note: Optional, disputed and redundant (references to sub levels 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.

Notes

Individual ways do not have to form a closed shape, as Areas do, but all ways collectively should form closed rings comprising the border. For a not-closed, linear border proposal, see Proposal:Relation boundary segment.

Object description tags

Many key values exist in OSM to describe "the object that a boundary relation represents"; for example, "The United States", or "Yellowstone Park". This might include a nation's population=*, the operator=* of a national park, or the name of a political entity in other languages. It is easiest for data consumers to expect a node they must read these from, rather than a relation (some machine data consumers don't understand what relations are at all)! For this reason, and to avoid duplication of effort by putting the same kinds of description tags on both a relation node and the relation itself, it's recommended that object description tags for a relation be placed on a member node tagged with type=boundary. This provides machine readers with a single source of truth for object description tags, while also providing all the benefits of describing a boundary area that a relation can provide.

Way tags

Member ways of any relation of type=boundary should have boundary=administrative and the admin_level=* for the highest border (when a country, state, county are on the same way the admin_level would be 2). source=* is always recommended.

Relations describing an Administrative Boundary should have boundary=administrative and the admin_level=* for the highest border (when a country, state, county are on the same way the admin_level would be 2). source=* is always recommended.

Because boundaries can be rendered both from relations and individual ways, tagging the ways is, in the strictest sense optional. There was a render issue (see this Github discussion), but this was resolved.

Boundary relationships are useful for many tools, but not necessary for rendering purposes, which is why boundary lines should be tagged to allow for the renderer to use them again.

Old direction dependent tags like name:left=*/name:right=* can be removed.

Avoid sharing boundary ways with ways describing physical features like woods or rivers – unless the boundary is legally defined by the physical feature (whether the edge, center, or other).

Examples

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.

Tagging examples
C is A's enclave and B's exclave: <relation id="1"> <tag k="type" v="boundary" /> <tag k="boundary" v="administrative" /> <tag k="land_area" v="administrative" /> <tag k="admin_level" v="2" /> <tag k="name" v="light green country" /> <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="land_area" v="administrative" /> <tag k="admin_level" v="2" /> <tag k="name" v="dark green country" /> <member type="way" id="AB" role="outer" /> <member type="way" id="AC" role="outer" /> </relation>	C is A's enclave and B's exclave.
D is an exclave of B, but not an enclave of A since it also shares a border with C: <relation id="1"> <tag k="type" v="boundary" /> <tag k="boundary" v="administrative" /> <tag k="land_area" v="administrative" /> <tag k="admin_level" v="2" /> <tag k="name" v="light green country" /> <member type="way" id="AB" role="outer" /> <member type="way" id="AC1" role="outer" /> <member type="way" id="AC2" role="outer" /> <member type="way" id="AD" role="outer" /> </relation> <relation id="2"> <tag k="type" v="boundary" /> <tag k="boundary" v="administrative" /> <tag k="land_area" v="administrative" /> <tag k="admin_level" v="2" /> <tag k="name" v="dark green country" /> <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="land_area" v="administrative" /> <tag k="admin_level" v="2" /> <tag k="name" v="purple country" /> <member type="way" id="AC1" role="outer" /> <member type="way" id="AC2" role="outer" /> <member type="way" id="CD" role="outer" /> <member type="way" id="BC" role="outer" /> </relation>	D is an exclave of B, but not an enclave of A since it also shares a border with C.

There are more examples!

Software implementation

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)
• role=(blank) for role=outer (note blank role is obsolete for multipolygons as well, but usually defaults to outer)

Tools

• OSM Inspector
• Relation Analyzer
• Relation Check

Downloads

• OSM Boundaries by User Wambacher
• Boundaries as download by mapzen.com