Proposal:Place areas

Place areas
Proposal status:	Draft (under way)
Proposed by:	Jojo4u
Applies to:
Definition:	Solutions for tagging settlements as areas.
Draft started:	2017-01-07

boundary=place

place=city_centre

place=town_centre

place=village_centre

Introduction

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.

Summary tables

Settlement with centre

	extend of large settlements	extend of small settlements	place centre of large settlements	place centre of small settlements	places without centre
Status quo	not mapped	`place=*` (uncommon)	`place=*`	`place=*`	/ `place=*`
Scenario A	`type=boundary` +`boundary=place` (member `boundary=*`)	`boundary=place` or `type=boundary` + `boundary=place` (member `boundary=*`)	`place=*`	`place=*`	/ `place=*`
Scenario B1	`type=boundary` +`boundary=place` (member `boundary=*`)	`place=*`	`place=*_centre`	`place=*_centre`	/ `place=*`
Scenario B2	`type=boundary` +`boundary=place` (member `boundary=*`)	`place=*`	`place=*`	`place=*_centre`	/ `place=*`

Dispersed settlements

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!

	extend of dispersed settlements	node somewhere in dispersed settlements
Status quo	`place=` (uncommon) or (multipolygon):* `place=*` (very uncommon)	`place=*`
Scenario A	`place=*`	-
Scenario B1	`place=*`	-
Scenario B2	`place=*`	-

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

Proposal for boundary=place

For settlements (or parts of) which have a centre the tag boundary=place is introduced to be used on:

closed ways (areas)
also on type=boundary relations.

The place/place-centre nodes are put in the relation as role place_centre.

Rationale:

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 solution is to separate landuse and place areas. Boundary ways are used, as already done by administrative boundaries, postal codes and low emissions zones.

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

The following place=* features usually don't not have a centre and can be represented as a closed way (area) tagged as place=*:

isolated_dwelling, farm, allotments, quarter, neighbourhood

For the following place=* features the the concept of a centre most likely does not fit. They can be represented as a closed way (area) tagged place=*:

city_block, plot and the "Key:place#Other_places" like square and island

Tagging for boundary=place

Using either:

a closed way (area) of boundary=place+place=*

or

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=*).

Additional tags:

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

A node of place=(place type)_centre (e.g. place=village_centre) is used to mark the commonly-understood centre of a place=* feature if the feature is tagged as area instead of nodes.

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.
wikidata=*
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.
capital=*
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?

A type=place relation could be used to link area and node together. Tags should be put on the relation. I see two problems:

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=*.

Scenarios detailed

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

Applies to

Rendering

Features/Pages affected

External Discussions

Closed tickets worth reading:

Comments

Please comment on the discussion page.

Proposal:Place areas

Contents

Introduction