Proposed features/place areas
|Status:||Draft (under way)|
|Definition:||Solutions for tagging settlements as areas.|
- 1 Introduction
- 2 Summary tables
- 3 Extent of settlements
- 4 Proposal for boundary=place
- 5 Proposal for place=*_centre
- 6 Scenarios detailed
- 7 Appendix - discarded scenarios
- 8 Applies to
- 9 Rendering
- 10 Features/Pages affected
- 11 External Discussions
- 12 Comments
place=* features are representing toponyms which are different from administratively declared borders (boundary=administrative). In the context of human settlements people usually refer to toponyms instead of the administrative entity. This leads to a side-by-side existence of places and administrative borders in OSM.
It is also a well understood principle of OSM that mapping spatial features as node is a precursor to the more detailed mapping as area.
The simple usage of place=* on areas faces four problems.
- A place=* feature should only be tagged either as node or as area (One feature, one OSM element).
- Mapping the place=* of large settlements cannot/should not be done with closed ways or multipolygons (explained below)
- If a mapper maps a place=* feature as area in order to detail the extent of a settlement the information about a centre is lost.
- A removal of place nodes would require action for many data customers.
This page describes two new tags and presents three scenarios how to use them. Scenario A looks like preferable on to me.
Settlement with centre
|place centre of
|place centre of
|Status quo||not mapped||place=* (uncommon)||place=*||place=*||/ place=*|
|Scenario A|| type=boundary
|Scenario B1|| type=boundary
|Scenario B2|| type=boundary
Dispersed settlements have no centre. Since all scenarios give alternative mapping methods for settlements with centres, settlements without centres can be mapped as place=* areas. The problematic multipolygonisation of landuse should be kept in mind!
|node somewhere in
|Status quo|| place=* (uncommon)
place=* (very uncommon)
An additional tag (e.g. dispersed_settlement=yes) could mark this type of settlement. Although this looks more like a job for Wikidata, it might mark the reason why this settlement is tagged without centre.
Extent of settlements
See also: Settlement geography
The extent of a settlement does not always fall together with the administrative border. Examples are:
- Metropolitan areas like famously Tokyo which consists of "special wards".
- Large rural non-populated areas like the suburb of Stuttgart-West ( / )
- Municipalities where no settlement of the same name exists Filderstadt ( /largest: )
- Administratively joined cities like Villingen-Schwenningen ( / / ) or Dessau-Rosslau ( / / .
The extent is also not exactly definable and depends on local knowledge and national or even local culture.
It usually goes along landuse categories (see Landuse)
- "Built environment" types are usually included
- "Agriculture": large forests and farmland are usually excluded, vineyards and allotments may be included
- "Leisure": Parks and village greens are usually included
Proposal for boundary=place
The place/place-centre nodes are put in the relation as role place_centre.
- Larger settlements (probably from place=city on) cannot by represented by a simple closed way (area) because this will be unmaintainable and there is also the issue of a 2000-nodes limit per way.
- The next solution would be Multipolygons. But they they do not support other roles than inner/outer.
- The next solution would be a a relation type=place. But then mappers will be tempted you use the edge of existing landuse=* areas members. This would lead to wide-spread use/conversion of landuse=* to multipolygons - which is a maintenance nightmare ("Multipolygonwahn").
The following place=* features most likely have a centre and for area representation the boundary approach should be taken:
- city, town, village, hamlet, suburb
- An exception are dispersed settlements
- isolated_dwelling, farm, allotments, quarter, neighbourhood
- city_block, plot and the "Key:place#Other_places" like square and island
Tagging for boundary=place
- a relation type=boundary+boundary=place+place=* using member ways of boundary=* with roles outer/inner. If appropriate boundary=* ways are already existing (e.g. administrative or postal_code) they can be used in the relation. Using natural=coastline is also possible. Otherwise create ways tagged boundary=place (without place=*).
- name=* - to facilitate handling
- admin_level=* - for linking to administrative borders, usually a place area is inside an administrative area
Other tags are not necessary since present on thenlinked place/place-centre node.
Proposal for place=*_centre
This node-only tag keeps the information of a an eventual centre if the place is mapped as area.
Tagging for place=*_centre
There are not too many tags on settlements and with the rise of Wikidata I would expect that only a handful make sense in OSM:
- name=* - with translations.
- population=* - gives importance for rendering, perhaps a bot could sync between Wikidata.
- ele=* - helpful for topografic maps. For the centre node ele=* stands for the settlement and not the point. There should be many settlements where the the commonly known centre is not on the official elevation.
- admin_level=* - for implicit linking to administrative borders
is_in=*- considered deprecated
addr:postcode=*- this is obsoleted by post code boundaries
All of the tags make sense for the node and the area. So all tags should be manually synced between the centre node and the area. This can be added to QA-checks and JOSM validator.
Why not using a relation?
- It is my belief that simple features in OSM should be implemented without relations where information must by retrieved by processing membership. Human settlements are arguably the second-most important features on OSM after highways.
- A relation would present another opportunity to put tags in. Result will often be 3 non-identical copies of the tags instead of two with this approach. This is common with the public_transport=stop_area relation of PTv2.
A data customer who wishes to link place and centre node can always do a spatial query using the place type and name=*.
There is a bit duplication (preliminary 4k in 2014) of place nodes and areas. These would need to be solved before declaring place areas safe to use. As the multipolygon challenge showed the OSM community is capable of this.
Scenario A - Boundaries on all places with centres
Although place boundaries are only technically necessary for large settlements they should be used for area representation on all place=* which have a centre in order to have consistent tagging. Places without a centre can be represented by place areas as they are usually smaller and more maintainable. The place node is kept.
+ Consistent mapping of place areas, place nodes are kept
− Area mapping places uses boundary=place instead of place=* which might confuse a bit
− Place areas decoupled from landuse
-> This scenario seems to the best solution
Scenario B1 - Boundaries large settlements only, place=*_centre everywhere
The place boundaries are only used on large settlements (probably from place=city on) which technically need it. Areas of smaller settlements can be mapped by a closed way (area) tagged place=*. In the centre of every settlement tagged as area (boundary and place closed way) the place=* node is renamed to place=(place type)_centre.
+ Intuitive mapping of small settlements and consistent mapping of place centres.
− Different area mapping depending on place size.
− All data customers have to take action in order to render places which are mapped as area. At least place=(place type)_centre on nodes added alongside place=* node processing.
-> This scenario seems to the the 2nd best solution
Scenario B2 - Boundaries large Settlements only, place=*_centre only on small
The place boundaries are only used on large settlements (probably from place=city on) which technically need it. The place node is kept. Areas of smaller settlements can be mapped by a closed way (area) tagged place=*. In the centre of small settlements tagged as area (boundary and place closed way) the place=* node is renamed to place=(place type)_centre.
+ Intuitive mapping of small settlements and backward compatibility for large settlements.
− Place centres for large and small settlements are mapped differently.
-> The backward compatibility costs too much. Settlements up to towns will not be presented if the data customer does not add place=(place type)_centre.
Appendix - discarded scenarios
Scenario C - Boundaries on large Settlements only, place=*_area as for small
The place boundaries are only used on large settlements (probably from place=city on) which technically need it. Areas of smaller settlements can be mapped by a closed way (area) tagged place_area=*. The place node is kept.
+ Place nodes are kept - The different mapping of areas disqualifies this proposal,
Scenario D - Relation as collection
A relation could be used to include all landuse which make up the settlement.
-Against the rule Relations/Relations_are_not_Categories and a maintenance nightmare
Please comment on the discussion page.