Proposed features/sidewalk schema

From OpenStreetMap Wiki
Jump to: navigation, search
sidewalk schema
Status: Draft (under way)
Proposed by: mdrouhard
Tagging: [[Key:*|*]]=[[Tag:*=*|*]]
Applies to: node,way,area,relation
Definition: comprehensive mapping for pedestrian ways
Rendered as: Various
Drafted on: 2016-06-29


This proposal is a standardization effort that promotes annotating sidewalks (and crossings and curb ramps) with their own geometries and tags, separate from their associated road(s). This proposal does not propose any new tags, but does propose standardizing their use when describing sidewalks, curb ramps, and street crossings, as well as associated features.

Recommendations for tagging sidewalks are often inconsistent and suggest two very different strategies: (1) tagging streets with sidewalk=both/right/left or (2) creating separate geometries and tagging them as highway=footway + footway=sidewalk. The following proposal is therefore two-pronged, (1) detailing the extensive limitations of tagging streets with sidewalk information and (2) recommending a standard for tagging sidewalks, crossings, and curb ramps with their own geometries.

Changes Proposed

Why not tag sidewalks as attributes of streets?

Currently, sidewalks are often tagged as properties of streets (highway=* + sidewalk=both/right/left). Unfortunately, sidewalks-as-street-tags have several limitations, many of which are described for each feature in the Rationale section. The subsections below summarize some of the limitations, most of which come down to the difficulty, and sometimes prohibitive complexity, of encoding basic pedestrian information if sidewalks are attributes of street nodes and ways. With that said, this proposal does not yet recommend the deprecation of sidewalk=*, particularly when the local community prefers it.

Mapping with sidewalk=* is indirect and requires advanced user input

Rather than drawing a sidewalk feature where it exists geospatially, mappers add sidewalk=* to a street. During this process, the mapper must keep track of the direction in which the associated street has been drawn. As a corollary, there is typically no visualization to indicate where sidewalks have been correctly annotated. JOSM plugins exist to address this limitation, but don't (and likely cannot) overcome the way that street crossings and curb ramps must be annotated in the sidewalks-as-street-tags schema. Changes to the renderer could address the visualization problem, but this also has limitations (see the next subsection).

Due in part to the roundabout way in which mappers must learn about and use sidewalk=* sidewalks in general are infrequently mapped and coverage is spotty. Sidewalk tagging is not easily discoverable for new users

sidewalk=* does not accurately describe sidewalk geometries

As an attribute of the street, sidewalk=* contains no geometrical information. While it is often the case that sidewalks match their streets' geometry (with an offset), there are numerous notable exceptions (include a graphics for each example). Complex intersections may have small islands of sidewalk, sidewalks may (or may not) extend through the centers of boulevards, and sidewalks can veer away from the street for significant stretches.

The lack of geometrical representation also impacts the meaning of features that live near or on sidewalks, such as bus stops, patches of grass, trees, and cycleways. For example, if the renderer were modified to display sidewalks on the side of appropriate streets, where would the sidewalks be placed? In reality, a sidewalk may be separated from the street by a raised patch of grass or cycleway, which could be individually mapped, but if sidewalks were rendered immediately next to streets, the opposite impression would be given: the sidewalk is next to the street, and grass and cycleways even farther away. Another proposal, the sidepath_tagging_schema, illustrates this situation well, and proposed an extremely complex tagging scheme to overcome the problem of eschewing a graph network to describe the pedestrian and cycle-only networks.

Realistically, it is not possible to accurately render sidewalk=* without knowing exact offsets from the road, which is more or less equivalent to creating a separate (and less accurate) sidewalk geometry.

Street crossings are points when using sidewalk=* (and curb ramp information is lost)

Street crossing information is currently encoded in various formats in OpenStreetMap, and is mapped even less frequently than sidewalks. The most common way of encoding a street crossing is as a node on a street that can include many relevant types of information, like whether the crossing is marked, has tactile pavement, or curb ramps on both sides. This has several significant limitations:

  • In reality, street crossings are relatively large and are themselves pedestrian paths (i.e. they are conceptually edges, or ways), so it is unintuitive to add them as a point feature.
  • Navigation, particularly self-planning pedestrian routes, is extremely complex. For example, imagine that a wheelchair user is on the 'right' side of a sidewalk and is coming up on an intersection, and the sidewalk ends at this intersection (i.e., they cannot turn right and stay on the sidewalk, they must cross) (see the figure below). In terms of the sidewalk=* representation, the valid path involves (1) traveling along the sidewalk (somehow having determined the meaning of sidewalk=right) to the street intersection, (2) taking a right turn onto the next street way, even though it explicitly has a sidewalk=no tag, (3) following the crossing placed on that sidewalk-lacking street, and (4) traveling back to the street intersection, again on a way marked with sidewalk=no. This series is both unintuitive for self-planned trips and in no way conducive to automated routing solutions.
Sidewalks as tags Sidewalks as ways
Diagram showing self navigation with sidewalks as attributes of streets in OSM
Self navigation with sidewalks as attributes of streets in OSM
Diagram showing self navigation with sidewalks as ways in OSM
Self navigation with sidewalks as ways in OSM

Curb ramp information is lost

Information about the ends of crossings, including curb ramps, is lost. How would a mapper say that there is a curb ramp on one side, but not the other? How would they indicate that a curb ramp is 3 cm high on one side, and 10 cm on the other? This problem extends to any attempt at describing the different properties of street corners that are relevant to the crossing. Currently, wheelchair=yes or wheelchair=no are used to include accessibility information, which requires the mapper to be overly broad in interpreting accessibility for users with a wide range of abilities (e.g. one individual may require curb ramps with a less than 3 cm curb, while another may not care about curb height). Similar situations apply for other users that need knowledge of kerb types (blind or limited vision users) or complex intersections with islands that are difficult to summarize with a single tag.

Curb ramps are more often annotated as separate points, in which case they either do not interface with the transportation network at all (points floating separately from streets) or are part of a pedestrian network, with sidewalks drawn with separate geometries.

Features/Pages affected

We propose three primary convention changes to OSM to support routing and other use cases for pedestrian paths:

  • Sidewalks should be ways (a sub-class of footways) that are routable and have the same properties as highway=*
  • Crossings should be ways that connect pedestrian paths (including sidewalks) and interface with other types of streets (through the nodes that currently specify crossings on highway=*)
  • Kerbs should be points that serve as an interface between pedestrian paths and crossings (with kerb properties indicated by existing kerb tags kerb=* )
Type Existing Geometry Proposed Geometry Tag(s) Notes
Sidewalk n/a Way (proposed) highway=footway + footway=sidewalk (proposed) recommend sidewalks be mapped as ways independent of streets
Crossing Node Way Way highway=crossing, railway=crossing, cycleway=crossing, footway=crossing (proposed) recommend crossings be mapped as ways
Kerb Node Way Node barrier=kerb, kerb=*, kerb:height=X.X(␣unit) (proposed) recommend kerbs be mapped as nodes on ways


Sidewalks provide a primary mode of travel that supports nearly all other travel options, leisure, recreation and community activities. This project seeks to make pedestrian ways, particularly sidewalks, first class members of an open data transportation network. The OpenStreetMap (OSM) project has made available extensive, user-contributed open data on transportation networks, providing the basis for many use cases and downstream activities, including rich analytics, travel route optimization, city planning, and disaster relief. However, footpaths in the built environment have generally been treated an addendum to streets.

Our rationale for each proposed change is described in detail below:

Sidewalks as Ways

  • According to Routing/online_routers, routing options for pedestrians, wheelchair users, and blind persons significantly more limited than other routing use cases.
  • For OSM users it is difficult to understand a pedestrian network that is not represented as a network but rather as attributes of nodes and ways
  • For routing purposes the cost of storing the necessary information for pedestrian routing is equivalent regardless of the network's representation ie: whether it is stored as a network or attributes of another network the cost is equivalent.
  • Routing that interfaces with other modes of transportation requires the representation of the pedestrian network to be a graph
Ground Conditions Existing OSM Representation Proposed Representation
sidewalk ground conditions at E Harrison and 12th Ave, Seattle WA
Sidewalk ground conditions at E Harrison and 12th Ave, Seattle WA
Sidewalk existing OSM representation at E Harrison and 12th Ave, Seattle WA
Existing OSM sidewalk representation
proposed sidewalk representation at E Harrison and 12th Ave, Seattle WA
Proposed sidewalk representation

Crossings as Ways

Crossings of major streets are currently implemented primarily as points. This structure has the following limitations:

  • Crossings are presumed to cross one and only one street
  • Spatial features of crossings cannot be represented meaningfully
  • Pedestrian routing applications must take on additional overhead to infer and route across these routes.

Crossing annotations as outlined in the footway=crossing tag address the above limitations. Additionally, annotating a pedestrian way with an associated crossing point on a major street provides and interface between the two for multi-modal routing.

Ground Conditions Existing OSM Representation Proposed Representation
Crosswalk ground conditions at E Harrison and 12th Ave, Seattle WA
Crosswalk ground conditions at E Harrison and 12th Ave, Seattle WA
existing crossing representation at E Harrison and 12th Ave, Seattle WA
Valid OSM crossing representation
Proposed crossing representation at E Harrison and 12th Ave, Seattle WA
Proposed OSM crossing representation

Kerbs as nodes

The tag kerb=* is defined as an interface between a sidewalk and a street, and the most common usage is with a node. We propose that the convention of tagging kerbs on nodes (as opposed to ways) be encouraged for the following reasons:

  • At present in OSM the tag kerb=* is most commonly used to indicate the presence of kerb ramps
  • As interfaces between different types of ways, kerbs should ideally be represented as nodes for routing purposes
  • The attributes associated with kerbs (e.g., kerb=lowered, kerb=raised, kerb=rolled) are generally used to distinguish between accessibility for various types of vehicles, assistive devices, or other needs at the endpoint of a particular crossing
  • Annotating kerbs as nodes provides a clearer spatial representation of the critical information for most map users
  • Annotating kerb=flush or kerb=no is particularly important in routing for users with low vision.
  • Annotating kerb=* with landing_width=*, allows users to determine if curb ramps have been built according to ADA standards, which require curb ramps with returned curbs have a landing with maneuvering space at the top of the ramp.
Ground Conditions Existing OSM Representation Proposed Representation
kerb ramp ground conditions at E Harrison and 12th Ave, Seattle WA
Kerb ramp ground conditions at E Harrison and 12th Ave, Seattle WA
existing kerb ramp representation at E Harrison and 12th Ave, Seattle WA
Current valid OSM kerb ramp representation
Proposed kerb ramp representation at E Harrison and 12th Ave, Seattle WA
Proposed kerb ramp representation

Pedestrian Layer

We also propose an OSM rendering layer for pedestrian ways. This layer has similar properties to the OpenCycleMap layer but serves different use cases, including facilitating routing for people with limited mobility.

Components of the layer would include any ways that allow foot traffic ("pedestrian ways") as well as core features of such ways. These components are described in greater detail below.

Existing Pedestrian Network:

Type Geometry Tag(s)
Crossing Way Node (proposed) highway=crossing, railway=crossing, cycleway=crossing, footway=crossing (proposed)
Cycleway Way highway=cycleway
Footway Way highway=footway
Path Way highway=path
Pedestrian Way Area highway=pedestrian
Sidewalk Way (proposed) highway=footway + footway=sidewalk (proposed)
Street Relation highway=* (used to link multiple associated ways)

Core Features of Pedestrian Ways:

Type Geometry Tag(s)
Amenities Node amenity=drinking_water, amenity=bench, amenity=shelter, amenity=toilets, amenity=water_point
Barriers Node Way Area barrier=*
Bike Access Way Node Area bicycle=*, bicycle=yes, bicycle=no
Foot Access Way Node Area foot=*, foot=yes, foot=no
Handrails Way handrail=yes/no handrail=left/right
Incline Way incline=up, incline=down, incline=x%, incline:across=x%
Kerb Node (proposed) barrier=kerb, kerb=*, kerb:height=X.X if measured in default SI unit (m) no unit is necessary, otherwise height should be followed by unit with space kerb:height=X.X in per OSM convention
Landing Width Node (proposed) landing_width=*, for use with kerb=*, if measured in default SI unit (m) no unit is necessary, otherwise height should be followed by unit with space
Linked Pedestrian & Motorways Relation (proposed) TBD (proposed)
Lit Way Node Area lit=24/7, lit=yes, lit=no, lit=automatic, lit=operating times
Ramps Way ramp=*
Smoothness Way Area smoothness=*
Surface Way Area surface=*
Tactile Paving Way Node Area Relation tactile_paving=*
Wheelchair Access Way Node Area wheelchair=yes, wheelchair=no, wheelchair=limited, wheelchair=designated
Width Way Node Area width=*

Related External Discussions

Referenced by User:Hubert87 in proposal sidepath_tagging_scheme:

Related Proposed Features

Proposal Development

This proposal is the result of the 2016 Data Science for Social Good (DSSG) program sponsored by the University of Washington eScience Institute, in collaboration with Urban@UW and Microsoft, which took place from June 13th to August 19th, 2016. The list of all DSSG participants on the Global Open Sidewalks team can be found below:

Will you please fill your user pages?

Global OpenSidewalks Website


Please comment on the discussion page.