Relation:boundary
- Other languages
boundary
|
|
For grouping boundaries and marking enclaves/exclaves.
|
|
Group:
boundaries
|
- - outer
- - inner
- - admin_centre
- - label
- - subarea
|
|
Status:
de facto
|
|
|
boundary
=*
relations
are used to define political, administrative, nature protection and similar boundaries. They are defined in a similar manner as
multipolygons
: they must contain at least one outer way, and additional ways can be used to define
enclaves
or
exclaves
.
Boundaries represented by relations can be topologically and logically nested within one another. For example, provinces of a country share some of their borders with the country, and some with other provinces mutually. Thus, one boundary way may participate in multiple boundary relations simultaneously (e.g. of a country, a province, a district and a municipality). Such approach make it easier to stitch all the parts of a border and avoid multiple duplicated ways above each other.
While some boundaries are physically visible, being clearly marked or placed over physical features such as rivers, many are not
verifiable
on the ground and sometimes must be
imported
from external sources. However, avoid connecting boundaries to physical features like woods or rivers or reusing their ways as boundaries (
one feature, one OSM element
). Sooner or later these features change in reality and get updated in OSM ? but usually the shape of the boundary remains. An exception may be done if the boundary is legally defined to be the physical feature.
Way tags
Boundary areas can be rendered both from relations and from individual closed ways. Relations also allow treating it as entire object in all cases allowing, for example, better labelling.
Boundary ways may have
boundary
=
administrative
and the
admin_level
=*
of the highest border (when a country, state, county are on the same way the admin_level would be 2).
source
=*
is always recommended. However, this tagging is optional, since data consumers can infer this information from the relations the way participates in; thus, boundary ways may be left completely untagged, as with multipolygons.
[1]
Historically,
name
:
left
=*
,
name
:
right
=*
,
nation
:
right
=*
, and
region
:
right
=*
have been added to boundary ways to define administrative divisions on their left and right side. Being cumbersome and error-prone, this method was has been replaced by one relation per country, province, city, etc. Old tags on ways like
name:left
=*
/
name:right
=*
can be safely removed.
Relation tags
Relation members
Element
|
Role
|
Occurrence
|
Notes
|
|
outer
|
!
1+
|
Ways, not necessarily closed, together forming (possibly, multiple separate) linear closed boundaries.
|
|
inner
|
?
0+
|
Forming, exactly as outers, boundaries inside of the outers which are excluded; i.e., enclaves.
|
|
<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.
|
Tagging examples
|
<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 is A's enclave and B's exclave.
|
|
<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 is an exclave of B, but not an enclave of A since it also shares a border with C.
|
- 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 support
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
admin_centre
role in some manner:
Tools
Downloads
References