The Future of Areas

OpenStreetMap doesn't have a native Area (or polygon) data primitive and areas are currently modeled using Ways which are also used to describe Polylines.

Not all closed polylines are areas, as this varies based on which other tags are present. A closed way tagged highway=footway is considered to be a circular path unless it has a area=yes tag which turns it into a pedestrianised area, however a closed way tagged with leisure=park is assumed to be an area. Areas can also be described using multiple ways as members of a relation:multipolygon. It is possible within the editors to create parks which are not closed even though these won't normally render unless they are included in a multipolygon. Anyone wishing to tag areas or use areas therefore needs to always check on the default usage of closed ways.

This set of wiki pages describes the problems and confusions created by the current model and suggests some alternative proposed approaches to model areas more clearly, flexibly and simply.

Contents 1 The current situation (Feb2012) 1.1 Way-based Polygons 1.2 Relation-based Polygons 1.3 Special Case: Coastlines 1.4 Special Case: Wide rivers 2 Problems with the current approach 3 'Simple features' 4 Proposals

The current situation (Feb2012)

There are currently two different ways of modelling areas/polygons in OSM: Way-based polygons and relation-based polygons.

Way-based Polygons

Polygons can be created from closed ways (ie. ways where the first and last node are the same). This is most often used for small polygons such as parks, buildings or small lakes.

What makes a closed way into a polygon are the tags used. If the tag refers to something that is an area (such as landuse=* or building=*) the way marks an area, if it refers to something that's a line (such as highway=* or railway=*) the way still is a line. So a roundabout might be described by a closed way, but that doesn't make it into an area. There is an extra tag (area=yes) to turn line features into area features, so a way with highway=pedestrian and area=yes describes a pedestrian area (such as a market place in a city).

Polygons modelled as closed ways can not have inner rings, ie. they can have no holes. It is not possible to define multipolygons (with several outer rings) this way.

Relation-based Polygons

See Relation:multipolygon.

Polygons modelled with relations can have inner rings, ie. they can have holes. They can also have multiple outer rings so they are proper multipolygons.

Note that there is some confusion where the tags for the multipolygons go. Sometimes they are tagged on the outer ring(s), sometimes on the multipolygon relations and sometimes on both.

Special Case: Coastlines

Coastlines can be seen as the boundary between land polygons and sea polygons. But in OSM they are handled in a different way. See Coastline and natural=coastline for details.

Special Case: Wide rivers

Rivers that are too wide to be mapped as line features are mapped with waterway=riverbank. Basically they are mapped as a set of way-based polygons attached end-to-end. What makes this case special is that you have to aggregate those polygons into one larger polygon for the whole river, the polygon parts do not really stand on their own. There is some confusion how this is to be done, especially when islands are involved. Sometimes relation-based polygons are used instead. The tag riverbank comes from the early times of OSM when only the riverbanks were tagged like this and these ways were not connected into polygons.

Sometimes other large areas (such as forests) are arbitrarily broken up into smaller polygons, too.

Problems with the current approach

There are several problems with the current situation:

• The current situation with several different ways of creating areas/polygons is difficult for people to understand and to work with.
• The different ways of solving what is essentially the same problem create problems for software development. More software and more complex software is needed. Software that works with one of the area types doesn't necessarily work with others.
• changes to mulitpolygon constructs are difficult and often damage the construct
• To create an actual multipolygon that can be rendered or otherwise worked with from relations, ways, and nodes is rather complex. Only a few people have actually implemented software that does this. There are numerous corner cases and possibilities to create invalid multipolygons. Assembling multipolygons from an OSM data file is difficult, because you either need to read relations first and then find the corresponding ways and then the nodes, or you need to keep nodes and ways in memory until you read the relation section. Even worse: Simple polygons (ie. closed ways) can not be used without checking whether they are actually part of a multipolygon relation.
• Even less software can assemble coastline data into something that is usable for the renderer.
• There is no way to find out if a closed way is a linestring feature or a polygon feature without having a list of tags and tag combinations. It is difficult to write generic software that handles those cases differently.
• evaluation of multipolygons is ill-defined and difficult, producing different renderings and different problems in different maps instead of a similar picture. Most useful software by third parties using OSM data can't evaluate multipolygons at all.
• way-based and relation-based polygons are incompatible. Describing the same real-life feature may require changing the type of polygon description used as more detail is added, this requires a complete rework and is prone to error.
• The current situation where semantic information is needed to figure out whether a way represents an area or a line is awkward and sometimes even undecidable.
• Because multipolygon relations are simply collections to the server/database, it is fairly easy to commit changes that break a multipolygon relation - in other words, because multipolygons are semantic, they break in ways that we don't see with way data (where the topological relationships are enforced in syntax).
• Tagging multipolygons is not straight forward either. A simple polygon has only one closed way which is holding the tags. For relation based polygons the relation feels to be the more logical element to be tagged. However, this is enough for making editing much more complicated: If a polygon is born as a simple one (building), but then evolves later into a relation (building with inner court), then the tags should be transferred. It is also possible that the inner rings are also objects which need their own tags (islands in a lake), similarly parts of multipolygons with many outer rings (islands which are together building up an archipelago).
• Because it is difficult to create large areas in OSM, often several smaller areas are created right next to each other. This often leads to bad rendering when the outline of the area ('casing') is drawn in a different color than the area itself. Lines in the outline color will cross the area. Also it makes labelling and other uses of the data more difficult when there is not one OSM object but several objects describing only one real-world object.
• Feel free to add your own

'Simple features'

The Simple Features model. (Look here for some definitions of words.)

• Issues to keep in mind for a new solution.

Proposals

Proposed solutions should ideally address all the problems and issues identified above. Partial solutions may however be useful as a basis.

Here are various proposals:

• The Future of Areas/Areas on Nodes
• The Future of Areas/Areas on Ways
• The Future of Areas/Areas on Nodes or Ways
• The Future of Areas/Tagging Outlines
• The_Future_of_Areas/Relation alternatives to Multipolygons
• The_Future_of_Areas/Triangles
• The Future of Areas/Super Areas
• Proposed features/Street area
• Relations/Proposed/Area
• Proposed features/area:highway