In an open way (a linear representation of a 要素) the first and last node are not identical. Common examples of linear representation with open ways include most roads, streams and railway lines, because these start in one place and finish in another.
In the database, a way always has a direction. This is true even if the ground feature it represents is 'two-way' (e.g., most roads, where traffic passes in both directions) or has no direction (e.g., a wall). See here for how to identify the direction of a 'way'.
In a closed way the last node of the way is identical with the first node. A closed way may be interpreted either as a closed polyline (a linear representation of a feature), or as an area representation of a feature, or both, depending on its tags and the tags on its relations .
The following closed ways would be interpreted as closed polylines:
- highway=* Closed ways are used to define roundabouts and circular walks
- barrier=* Closed ways are used to define barriers, such as hedges and walls, that go completely round a property.
A closed way that has the tag area=yes should always be interpreted as an area (but the tag is not required most of the time: see 'area', below).
Overpass QL parameter/operator
is_closed Overpass_QL#Geometry_Related_Operators & example overpass-turbo query: Overpass_API/Overpass_API_by_Example#Limit_results_to_areas_only
An area (also polygon) is an enclosed filled area of territory defined as a closed way. Most closed ways are considered to be areas even without an area=yes tag (see above for some exceptions). Examples of areas defined as closed ways include:
For tags which can be used to define closed polylines it is necessary to also add an area=yes if an area is desired. Examples include:
- highway=pedestrian + area=yes to define a pedestrian square or plaza.
Areas can also be described using one or more ways which are associated with a multipolygon relation.
There are different methods for modelling the same real world features in Openstreetmap. For instance a linear representation of a highway is a common although specific form of modelling geographical data, often geared more towards creating routable networks then an accurate representation of what is actually on the ground:
- features in the real world such as a highway have a certain width -that may change gradually-, but a linear representation has by itself no geometrical representation in nodes of its (change in) width, but perhaps only a tag stating an average width. Therefore with a linear representation a mapper must choose a center line, for which there can be various options, especially when the feature itself is asymmetrical in its cross-section (options: center of carriageway vs center of carriageway + sidewalk vs location of directional markings on carriageway)
- Another example of specific properties of linear representation is that on a crossing of a gravel track with an asphalt road -where the crossing itself is asphalt- the linear representation of the gravel track is continued over the crossing, as if the crossing might be gravel as well
- Linear representations of highways also tend to be continued in Openstreetmap while in the real world the highway briefly physically ceases to exist as a separate entity and only remain as a functional connection, such as a highway crossing a stream in a ford over the riverbank without additional infrastructure, or stepping stones where the space between the stones may be larger than the stones themselves.
These are fundamental differences with an area representation of the same feature, where the (change in) width of the area is described by its nodes and the area representation of a highway (and stepping stones functioning as a highway) will end in the examples above where the linear representation is continued.
Both methods have their use and can be used: linear representation is often easier to start with and gives routable networks, while area representation gives a more accurate description of the actual shape of a feature.
A one-way residential street, tagged as highway=residential + name=Clipstone Street + oneway=yes
<way id="5090250" visible="true" timestamp="2009-01-19T19:07:25Z" version="8" changeset="816806" user="Blumpsy" uid="64226"> <nd ref="822403"/> <nd ref="21533912"/> <nd ref="821601"/> <nd ref="21533910"/> <nd ref="135791608"/> <nd ref="333725784"/> <nd ref="333725781"/> <nd ref="333725774"/> <nd ref="333725776"/> <nd ref="823771"/> <tag k="highway" v="residential"/> <tag k="name" v="Clipstone Street"/> <tag k="oneway" v="yes"/> </way>
The nodes defining the geometry of the way are enumerated in the correct order, and indicated only by reference using their unique identifier. These nodes must have been already defined separately with their coordinates.
An OSM way is specified by a collection of nodes. The way is made up by the way segments connecting these nodes. Each segment is assumed to be the shortest line on the Earth's surface (negating terrain issues) connecting its two ends, i.e. a geodesic on the figure of the Earth used. The figure can be a sphere (as used in Web Mercator; see Spherical trigonometry), or an ellipsoid for higher precision (see Geodesics on an ellipsoid). The main effects for the end-user and the programmer would be:
- Long segments should look bent on maps rendered using a Mercator projection.
- The length of long segments are only correct with a geodesic-aware algorithm.
Actual OSM nodes should be close enough to each other to not warrant such worries, although measurements of area is another story. Most of the math can be found in the source code for JOSM/Plugins/measurement.