Area/The Future of Areas/Simple Features
Simple Features is a standard way of modelling geographic information. It differentiates between geometries with the information on location (such as points, lines, polygons, etc.) and features representing real world objects and their properties (like a signpost, a fence or a forest).
See this wikipedia article for links to the specs related to geometries, and this about features.
OSM and Simple Features
Simple Features is a widely deployed standard in the GIS industry. Almost all software that handles spatial data uses Simple Features as a data model. OSM uses a different data model which has advantages and disadvantages when compared to the Simple Features model.
OSM will probably never switch to the Simple Features model, but it makes sense to think about how those two models are different and where we can use ideas from it. We also have to define a mapping between OSM and Simple Features (in both directions), because so many software uses the Simple Features model. For nodes (that map to a Simple Feature "Point") and ways (that map to a Simple Feature "LineString") this is straightforward. For areas/polygons this is much more difficult. This has hampered the use of OSM with software that is using the Simple Feature model.
Mapnik rendering is based on the Simple Features model. Osm2pgsql is converting native OSM data into PostGIS database and the resulting tables osm_point, osm_line and osm_polygon are all filled with Simple Features.
Word Definitions
The simple feature model defines certain words in certain ways. To make discussions easier, we should use those words with those meanings and use different words for OSM concepts that might be similar but don't match the definitions.
Please read up on those definitions in the Simple Feature Access - Part 1: Common Architecture.
Table 1 is a high-level view on the classes in Geometry class hierarchy of the standard (Figure 1) that might help in discussing any mapping between OGC- and OSM-terminology. Table 2 is a closer look at mapping of terms that is not restricted to elements on the OSM-side, with a focus on the concept of “area”.
"Correspondence" in these tables does not mean that the terms have identical definition – there are many characteristics that do not match. Perhaps the most notable difference between the models is the strict distinction between “geometry” and “feature” in OGC (see Feature Modelt : “A feature is a representation of a real-world object. For spatial applications, the most important property of a feature is location which will be dealt with in later parts of this standard on geometry …”). This distinction is not so clear in OSM: does a mapper understand a “route" to be a geometry (i.e. it maps to OSM-mulitline) or as a feature (e.g. a trail with properties like name or quality)? In the context of the OSM-area it is the distinction between “area” (a feature) and surface / polygon (a geometry).
| Basic unit | Example
(other geometries) |
Corresponding OSM-element | Comment |
| (none) | tag | In OGC-terminology OSM-tags are used to define features (see OGC-definitions for ontology and feature property ) | |
| 0-dimensional geometry | Point | node | |
| 1-dimentional geometry | LineString
(Curve, Line, LinearRing) |
way | |
| 2-dimensional planar geometry | Polygon
(Surface, Triangle) |
(none) | Implementing an OSM-element “area” with a close match to OGC-polygon would fit well into this table |
| 2-dimensional non-planar geometry | Polyhedral Surface
(Surface, Tin) |
(none) | Probably there are no OSM-objects fitting into this category unless the elevation becomes relevant part of the coordinates of an OSM-object. |
| collection of geometries | GeometryCollection
(MultiPolygon, MultiLine, ….) |
relation |
| OGC-geometry
(chapter of the standard) |
characteristics, comments | Corresponding OSM-term / feature based on the geometry |
| LineString
(6.1.7) |
LineString as the only subtype of curve (4.7, 6.1.6) | Way |
| Simple curve / LineString | does not pass through the same Point twice with the possible exception of the two end
points. Point here means an element of the set, not the points that are used to define the curve / LineString |
-
“simple” is not defined in OSM |
| Closed curve
(6.1.6.1) |
if its start Point is equal to its end Point | Closed way |
| Boundary
(4.1, NOTE in 4.7) |
Set that represents the limit of an entity.
Here: the outer and inner boundaries of an area. |
Closed ways that are tagged role=”outer” or role=”inner” |
| LinearRing
(6.1.7) |
Closed and simple LineString | -
not defined although a closed ring is mentioned in Relation:multipolygon/Algorithm#Ring Assignment |
| MuliLineString
(6.1.9) |
Route | |
| closed simple MultiLineString
(Fig. 9 allows this) |
-
There is no “closed route” defined in OSM | |
| Surface = polygon
(6.1.11) |
planar surface with one “exterior boundary” and 0 or more
“interior” boundaries, so that the interior is connected (see 6.1.11 for precise definition ans assertions) |
Area |
| MultiSurface = MultiPolygon
(6.1.13, 6.1.14) |
Collection of polygons | Multipolygon
(but with problems - see below) |
A problem with mapping the current OSM-MultiPolygon to OGC-Multipolygon is that the polygon is missing in the OSM-concept:
- does the OSM-multipolygon represent one area or a collection af areas? The page on Area says "An area ... can be defined ... using a multipolygon relation creating an area ..." suggesting that one MP represents one area, while the different shades of gray in Relation:multipolygon#Island within a hole suggest a 1:n relationship between M and area.
- Where do the tags defining the properties of the area go?
- A lake in a forest could be considered to be a hole in the forest filled with a lake, while a house could be considered to be a building on a residential area. Is it intuitive how to model these two situations?
- Is it required to consider areas made up from two disjunct patches (Talk:Relation:multipolygon#Advanced multipolygons: New use: More than one (disjunct) outer ring)?
The correspondenc would be closer if one postulates a 1:1 relationship between outer rings an polygons, and makes the inner rings part of the outer ring = polygon. Relation:multipolygon#Island within a hole would look like this:
<relation id="1">
<tag k="type" v="multipolygon"/>
<member type="way" id="1" role="outer">
<member type="way" id="2" role="inner"/>
</member>
<member type="way" id="3" role="outer"/>
</relation>
It would be clear that there are two areas modelled, and that all tags describing the areas go to the members referencing way#1 und way#2 and that the multiolygon realation should not be tagged with properties of single areas.