User:Skybunny/Relation:boundary

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — Relation:boundary
· Afrikaans · Alemannisch · aragonés · asturianu · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · Bân-lâm-gú · Basa Jawa · Basa Sunda · Baso Minangkabau · bosanski · brezhoneg · català · čeština · corsu · 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 · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tagalog · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · беларуская · български · қазақша · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · मराठी · हिन्दी · भोजपुरी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · བོད་ཡིག · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ ⵜⴰⵏⴰⵡⴰⵢⵜ‎ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 中文(繁體)‎ · 吴语 · 粵語 · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް
Public-images-osm logo.svg boundary
Boundary.png
Description
For grouping boundaries and marking enclaves/exclaves.
Group: Properties
Members

  • Way - inner
  • Way - outer
  • Node - admin_centre
  • Relation - subarea
Wikidata
Wikidata-logo.svgSearch Wikidata
Status: de facto

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
Way outer ! 1+ The multiple ways that form the closed border
Way inner ? 0+ Enclaves of this border - the multiple ways that form the closed inner borders
Node 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.
Node 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=*).
Node 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.
Way <empty>  0 Deprecated for boundary relations (see software implementation notes). Use the role outer instead.
Relation 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

Downloads