User:Skybunny/Relation:place
 boundary
|
 |
| Description |
|---|
For grouping boundaries and marking enclaves/exclaves. 
|
| Rendering in OSM Carto |
|
|
| Group: Properties |
| Members |
|
|
| See also |
| Status: de facto |
| Tools for this tag |
|
place=* relations are used for describing extents of places, marking enclaves/exclaves of them, and indicating significant locations related to them with additional nodes.
Relations are used rather than Areas in order to:
- Allow one umbrella OSM data structure per place (one feature, one OSM element)
- Simplify associating all the components of a place with each other
- Allow the sharing of ways which may describe multiple boundaries or places
See place=* for common types of tagged places, suitable to tag on the place relation.
Place relation tags
| Key | Value | Discussion |
|---|---|---|
| type | boundary | Required. |
| boundary | place | Required. |
| place | place type | Required. |
| name | A name | Required. |
| Deprecated for place relations (see software implementation notes). When found, boundaries with this tag should be migrated to type=place or type=boundary and checked for consistency. |
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 | ! 1 | Required. Node representing the location a navigation user should be routed to, if they select a place relation as a navigation destination. |
|
|
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 place 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. |
|
|
✗ 0 | Not supported. A place relation member must have a role. |
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.
Object description tags
Many key values exist in OSM to describe "the object that a place relation represents". This might include a settlement's population=*, the operator=* of a named place, or the name of the place 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 place relation be placed on the waypoint role node tagged with the place type, place=*. 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
Place relationships are useful for many tools, but it's helpful for rendering engines to have member ways to be tagged with a boundary=* tag, which is why place relation lines should be tagged to allow for the renderer to use them again. Member ways of type=place relations should have boundary=place added to the way – if a different boundary tag is not already assigned to the way (like boundary=administrative). source=* is always recommended.
Avoid sharing place relation ways with ways describing physical features like woods or rivers – unless the place is understood to be defined by the physical feature (whether the edge, center, or other).
Software implementation
Software should support all deprecated types until they disappear in database:
- type=multipolygon as well as type=place