Relation:boundary
 boundary
|
|
| Description |
| For grouping boundaries and marking enclaves/exclaves. |
| Group |
| Properties |
| Members help |
|
| Statistics |
boundary=* relations is used for grouping boundaries and marking enclaves/exclaves.
Relations are used in order to:
- Avoid name:left=*, name:right=*, nation:right=*, and region:right=*. This has been replaced by one relation per country, province, city, etc.
- Make it easier to stitch all the parts of a border to each other
- Avoid multiple duplicated ways above each other.
Contents |
Way tags
If boundary tags are added to member ways they 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), although if the relations are correctly defined then these tags are optional. source=* is always recommended.
Old direction dependent tags like name:left=*/name:right=* can be removed.
Relation tags
| Key | Value | Discussion |
|---|---|---|
| type | boundary | also deprecated type multipolygon is used (see software implementation notes) |
| boundary=* | administrative | for a real boundary (sometimes in the middle of a river or 12 Miles away from coastline) |
| land_area | administrative | for coastline and real boundaries on land |
| name | a name | |
| admin_level | the admin level |
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 | Recurrence? | Discussion |
|---|---|---|---|
|
outer | one or more | The multiple ways that form the closed border |
|
|
inner | zero or more | Enclaves of this border - the multiple ways that form the closed inner borders |
|
subarea | zero or more | 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). Also referencing other relations makes editing more complicated in some cases. |
|
admin_centre | zero or one | Node representing the administrative centre, usually a town, city or village (depending of the boundary level, see place=*) |
|
|
label | zero or one | Node representing where to draw the label. |
|
|
(blank) | one or more | Old, use outer instead |
|
|
enclave | zero or more | Old, use inner instead |
|
|
exclave | zero or more | Old, use outer instead |
Note: The ways don't have to be closed, But all ways together should form closed rings making the border. For not closed, linear border, see Proposal:Relation boundary segment.
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),exclave for role=outer (note blank role is obsolete for multipolygons as well, but usually defaults to outer)
- role=enclave for role=inner
- role=admin_center for role=admin_centre
- Note: Even if names differ, semantics are equal
