Proposal:Sidewalk schema
| sidewalk schema | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | mdrouhar,uwtcat,nbolten |
| Tagging: | [[Key:*|*]]=[[Tag:*=*|*]] |
| Applies to: | node,way,area,relation |
| Definition: | comprehensive mapping for pedestrian ways |
| Statistics: |
|
| Rendered as: | Various |
| Draft started: | 2016-06-29 |
Introduction
Sidewalks provide a primary mode of travel that supports nearly all other travel options, leisure, recreation and community activities. Pedestrian ways, particularly sidewalks, should be first class members of an pedestrian transportation network. However, many footpaths in the built environment have generally been treated an addendum to streets, hampering the ability to create a useful pedestrian network.
Proposal
This proposal/schema is intended to organize a holistic tagging approach to sidewalks (and related pedestrian infrastructure) based on separate footway=sidewalk + highway=footway ways. The tagging recommendations made on this page use either (1) tags that have already been accepted by the community, (2) tags that are clearly indicated as being used in certain ways in limited locales, or (3) tags that are clearly delineated as proposed ideas/problems that should go through a proper RFC/proposal/submission/voting process.
While it makes sense for many elements of this schema to have their own separate tagging pages (and most do), it can be difficult to know how to use pedestrian-related tags together to describe the infrastructure for a given area, particularly since tagging streets with sidewalk=* is currently more prevalent. This document seeks to describe best practices for tagging sidewalks as separate ways, as well as how to combine them with further subtags to adequately describe a pedestrian network useful for all pedestrians.
The goals of this proposal/schema:
- The schema should promote a data-driven understanding of pedestrian spaces, chiefly one that lends itself to a network interpretation.
- The schema should provide detailed information about the connected pedestrian transportation network, refraining from subjective or value-laden tags.
- The schema should make it easy to understand how to tag a pedestrian network, with a focus on sidewalks.
- The schema should meet the needs and preferences for a wide range of users, including people with limited mobility (e.g. a wheelchair user) and people with impaired vision.
Topics covered by this proposal/schema:
- The trade-offs between describing pedestrian ways separately vs. as attributes of another way.
- How to create a pedestrian network using separate ways: tying together sidewalks, crossings, streets, other footways, etc.
- How to enrich a pedestrian network with tags relevant to: (1) all users (2) different mobility profiles (including specific needs and preferences about attributes like elevation changes, certain types of surfaces like tactile̠ paving, or presence of certain barriers like kerbs)
- Identify current pain points / missing tags that should be turned into separate feature proposals.
While most of this proposal represents a standardization of common/accepted tags, it does identify some (clearly delineated) areas where new tags may be required / subject to proposal to the community.
Separate ways or no?
Recommendations for tagging sidewalks are include 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. While these strategies are not incompatible (you can tag both without breaking the other), this proposal/schema lays out the case for why separate ways should be the primary geometry for most use cases.
Tagging streets with sidewalk=both/right/left is not incompatible with also tagging sidewalks as separate ways. The following comparison is based on how descriptive these frameworks are, and why relying on sidewalk=both/right/left for anything more than street asset information is difficult.
Sidewalks as metadata vs. sidewalks as ways
| Ground Conditions | Using sidewalk=both/right/left | Using highway=footway + footway=sidewalk |
|---|---|---|
File:Sidewalks arial view.png Sidewalk ground conditions at E Harrison and 12th Ave, Seattle WA |
File:Existing OSM representation.png Sidewalks are described as street metadata (not displayed by default) |
File:Proposed OSM sidewalk representation.png Sidewalks are described with footpath lines |
Crossings as nodes vs. crossings as ways
| Ground Conditions | Using sidewalk=both/right/left | Using highway=footway + footway=sidewalk |
|---|---|---|
File:Exisiting Crosswalk.png Crosswalk ground conditions at E Harrison and 12th Ave, Seattle WA |
File:Existing OSM representation.png Crossings are nodes on the street |
File:Proposed OSM crosswalk representation.png Crossings are lines connecting sidewalks (and other footpaths) together across streets, and provide a means for interfacing the street network with the pedestrian network. |
Curb ramps as metadata of crossings vs. as node feature
| Ground Conditions | sidewalk=both/right/left | Using highway=footway + footway=sidewalk |
|---|---|---|
File:Existing kerb ramps.png Kerb ramp ground conditions at E Harrison and 12th Ave, Seattle WA |
File:Existing OSM representation.png Curb information is consolidated into a single point, and may be ambiguous. |
File:Proposed OSM kerb ramp representation.png Curb interfaces are separately described as nodes. Note: curb nodes should not be added *along* sidewalks unless there is literally a curb interface as you walk/roll along it. |
Mapping sidewalks as only street metadata is hard to extend and interpret
When tagging streets with sidewalk=both/right/left, the only geometrical information we have to work with is streets. As a result, many piece of information become ambiguous or nearly impossible to add:
Street crossing nodes can't describe essential information
Street crossings have to be modeled as a node with highway=crossing, and therefore every aspect of the crossing, including curb, surface, barrier, marking, controlled, direction, etc has to be encoded into that point:
- A crossing node with unbalanced curb information (one side is kerb=lowered, the other isn't) is ambiguous and requires interpretation by the user. What if one side has tactile paving and the other doesn't? What if one curb has a 1 cm displacement while the other has a 5 cm displacement?
- It's nearly impossible to represent the location of visible barriers along the path, such as raised kerbs or bollards, and have them factor into the network description.
- Offset information is entirely missing - how far away from the crossing is the curb ramp? Some curb ramps put people into traffic because of their poor location.
- Interpreting crossings becomes difficult and spatially inaccurate. To walk straight across an intersection from one sidewalk to another, a user (or a router) has to (1) be located on the sidewalk / street line (or edge), (2) encounter an intersection with a street, (3) traverse the next street over (left or right, depending on the current sidewalk side) for a short distance, if it also has a sidewalk on the 'inner' side, (4) encounter a highway=crossing node, (5) evaluate its accessibility/safety, (6) swap to the other side of the street, if a sidewalk exists there, (7) reverse course and travel back to the intersection, and (8) make a left/right turn depending on the original side of the street. See below:
sidewalk=*, highway=crossing footway=sidewalk, footway=crossing File:Self navigation with sidewalks as attributes of streets.pngSelf navigation with sidewalks as attributes of streets in OSMFile:Self navigation with sidewalks as ways.pngSelf navigation with sidewalks as ways in OSM
Sidewalk location can't be determined
Most streets lack the information necessary to accurately evaluate sidewalk locations: the street width is often missing, the sidewalk width if often missing, and there can be any number of features in between them that take up space, like trees, greenways, etc. As a result, asking the question, 'does this sidewalk intersect with X' becomes impossible, and rendering the location of sidewalks is inaccurate.
Pedestrian islands at intersections can't be (easily) represented
Take the example of the intersection of 7th Ave NE & NE 45th St in Seattle, WA. In this scenario, there are two pedestrian islands involved in crossing the street (and one also serves as a bus stop). The complexity of the intersection is exacerbated by the fact that it is not safe (and is possibly illegal) to cross north-south on the east side of the intersection, but there are clearly marked crossings connecting the islands themselves north-south. When using sidewalk=both/right/left, the islands would have no spatial representation and no connection to one another, existing merely as metadata (crossing=island or crossing:island=yes) on the highway=crossing node.
Even in the simpler traffic island scenario, where it's just an intermediate part of crossing a single street, adding further information to the crossing is now muddled, as any on-the-ground variation in surface, curb interface, tactile paving, crossing markings, traffic signals, etc for 2-3 crossings now has to be embedded into one node.
Cluttered street lines
Streets are already the home of information that varies along their centerlines: street width, lane number, lane markings, parking lanes/availability, curb information, though only width and lane info tends to get mapped. Sidewalks vary even more along their length, and there would often be two per street. The street would need to be split + annotated, or have a node added, every time one of the following is encountered:
- A width modifier: a tree, a mailbox, a lamp post, a bollard, a bench
- A surface change (metal grate, concrete, etc)
- A significant displacement (2+ centimeters): a tree root, a big crack, a big pothole
- A significant change in incline either along or orthogonal to the sidewalk
- A change in the curb along the side of the sidewalk
- A kerb interface encountered along the sidewalk (such as a dip when a driveway intersects it)
- Steps along the sidewalk
If there are just two variations per sidewalk, that's four places to split the street, and therefore five new segments of street. But if the information (such as surface) is for whole segments, you will need to select every segment for which it applies, and potentially split the street twice. If fully annotated, the street line would rapidly blow into pieces ~2-3 meters long, for common urban areas. For example, on one average block of 15th Ave NE in Seattle[1], we can count these sidewalk features/variations, per side, heading north:
West:
- Sidewalk bulb (width modifier)
- Curb ramp (width modifer)
- Row of trees (width modifier)
- Curb ramp (temporary curb change)
- Plaza (width modifier)
- Surface change (concrete to brick)
- Single tree (width modifier)
- Single tree (width modifier)
- Surface change (brick to concrete)
- Newspaper stand + light pole (width modifier, modifier of maneuverability at the crossing)
East:
- Traffic light pole (width modifier)
- Fire hydrant (width modifier)
- Defunct street lamp (width modifier)
- Street lamp (width modifier)
- Fire hydrant (width modifier)
- Street lamp (width modifier)
- Street lamp (width modifier)
- Curb ramp (width modifier)
If those width modifiers are treated as nodes (minimal disruption), we'd need to add a total of 14. Each would be of a format similar to `sidewalk:left:width=` (which is itself tricky if the street ways ever got accidentally reversed). In addition, the surface change would imply a minimum of 2 additional splits to the street, which has already been split twice to account for turn lanes. If this information were added to a separate sidewalk lines, there would be 7 width modifiers each, easily located along the actual sidewalk line, and with much simpler tagging along the lines of `width` or `width_modifier`.
Now, you may think: hey, couldn't we represent all these width modifications with something like a `min_width` tag? Perhaps, in some cases. However, pedestrian trips frequently start or end part-way down a given way (like visiting a business or crossing the street), so it would not be clear which segments should be annotated with different `min_width` tags.
Routing with sidewalks-as-street-metadata has all the same issues as doing so with separately-tagged ways, but carries less information
- According to Routing/online_routers, routing options for pedestrians, wheelchair users, and blind persons are significantly more limited than other routing use cases.
- 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.
Separately-mapped sidewalks are easier to automatically validate
Sidewalks-as-ways will naturally intersect with buildings and other ways, enabling better computer-aided mapping. For example, if a sidewalk intersects with a building's awning, JOSM can automatically detect this and suggest splitting the way and adding covered=yes.
Proposed schema
The tagging recommendations described here should not involve any new tags that aren't currently accepted or in use by various communities in the wild. Instead, they represent a holistic standardization for using ways and tags in conjunction to represent and annotate a pedestrian network.
The underlying pedestrian network
The fundamental elements of a pedestrian network are ways (paths) that describe places pedestrians can go to and from. In an urban environment, these includes sidewalks, street crossings, and paths within dedicated pedestrian regions, like parks or building plazas. In terms of tagging, this means:
- Sidewalks should be ways (footways) describing the centerline of actual sidewalk infrastructure.
- Crossings should be ways that connect pedestrian paths (including sidewalks) to and across streets.
| Type | Existing Geometry | Proposed Geometry | Tag(s) | Notes |
|---|---|---|---|---|
| Sidewalk |  
|
(primarily)
|
highway=footway + footway=sidewalk (proposed) | recommend sidewalks be mapped as ways independent of streets |
| Crossing |
|
|
highway=crossing, railway=crossing, cycleway=crossing, footway=crossing (proposed) | recommend crossings be mapped as ways, way extending from one curb interface to another curb interface. |
Connecting sidewalks and crossings
Exactly how do sidewalks and crossings get connected varies from region to region and person to person, and should be standardized. The challenge is whether a way describing a street crossing should connect directly between sidewalk centerlines, or whether small snippets of sidewalk should exist at each end, as the surface at that locations is technically made up of sidewalk (and there is an implied need to annotate the curb interface where they meet).
In lieu of an accepted standard (which should go through a proper RFC/proposal/submission/voting process), we can list one example: in Graz, Austria, and Seattle, WA, United States, mappers currently tag small sidewalk snippets at each end of a crossing. TODO: add a graphic illustrating this situation.
Annotating the pedestrian network
Many types of information are useful for annotating a pedestrian network, but tend to fall into a few categories:
- (potential) Barriers: generally nodes along the way
- Way attributes: surface type, width, etc.
- Amenities: generally nodes close to or on the way, such as a bench
(potential) Barriers
- 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 |
|---|---|---|---|---|
| Curb/Kerb |
|
|
barrier=kerb, kerb=*, kerb:height=X.X(␣unit) | If there is a curb interface along a way, it should be added as a kerb=* node. All (semantic-level) street crossings should ideally have at least two kerb=* nodes, even if the interface is flush. |
Sidewalk way attributes
| Type | Existing Geometry | Proposed Geometry | Tag(s) | Notes |
|---|---|---|---|---|
| Curb/Kerb |
|
|
kerb=*, kerb:height=X.X(␣unit) | Using kerb=* along a way implies that along (at least one) side of the way, there is a curb interface matching the tag value. It's implied that the kerb side being described is nearest to the street. |
Crossing-specific way attributes
| Type | Existing Geometry | Proposed Geometry | Tag(s) | Notes |
|---|---|---|---|---|
| Markings |
|
|
crossing=* | See: Key:crossing |
Topics that need to be further fleshed out / discussed
- Ramps (curb, wheelchair, etc)
- Incline
- Separate sections for tagging for common use cases: manual wheelchair, powered wheelchair, limited vision, blind, etc. Blind users often have opposite preferences from wheelchair users, such as hard and easy to identify curbs.
- Rendering
Existing tags to integrate into the discussion
| Type | Geometry | Tag(s) |
|---|---|---|
| Amenities |
|
amenity=drinking_water, amenity=bench, amenity=shelter, amenity=toilets, amenity=water_point |
| Barriers | 
|
barrier=* |
| Bike Access |
|
bicycle=*, bicycle=yes, bicycle=no |
| Foot Access |
|
foot=*, foot=yes, foot=no |
| Handrails |
|
handrail=yes/no handrail=left/right |
| Incline |
|
incline=up, incline=down, incline=x%, incline:across=x% |
| Kerb | (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 | (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 |  (proposed)
|
TBD (proposed) |
| Lit |
|
lit=24/7, lit=yes, lit=no, lit=automatic, lit=operating times |
| Ramps |
|
ramp=* |
| Smoothness |
|
smoothness=* |
| Surface |
|
surface=* |
| Tactile Paving |
|
tactile_paving=* |
| Wheelchair Access |
|
wheelchair=yes, wheelchair=no, wheelchair=limited, wheelchair=designated |
| Width |
|
width=* |
Proposals to be worked into separate RFCs
| Type | Existing Geometry | Proposed Geometry | Tag(s) | Notes |
|---|---|---|---|---|
| Curb/Kerb |
|
|
kerb:right/left=*, kerb:right/left:height=X.X(␣unit) | Curb information without a side is ambiguous. While most will be 'whatever side is closest to the street', this is frequently not the case. |
| Landing width | N/A | N/A | landing_width=* | The landing width of a curb ramp (or other ramp-ish feature). |
Related External Discussions
Referenced by User:Hubert87 in proposal sidepath_tagging_scheme:
- Radweg-Tagging
- Sidewalk als "echte" alternative zu dediziert getaggtem path
- Goldstandard Fußweg/Radweg an Straße
- Unterschiedung straßenbegleitener und eigenständiger Wege
- sidewalk die 1001
- Barrierefreies Routing mit OpenStreetMap (OSM)
- Kurze Frage zu footway=sidewalk
- Frage zur verwendung von Fußwegen
- Jetzt schon Bürgersteige mappen?
- Talk-de - cycleway=track bei Bordstein Trennung
- Feature Proposal - RFC - Sidewalk
- Sidewalks vs Footways[2][3][4]
- Tagging - Sidewalks vs Footways
- Fixing sidewalk tags on OSM - Mapbox
Related Proposed Features
- Proposed: sidepath_tagging_scheme
- Proposed: Sidewalk
- Proposed: foot_cycleway
- Draft: incline:across
- Abandoned: Advanced_footway_and_cycleway
- Abandoned: Footway
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:
- Nick Bolten, Project Lead
- Anat Caspi, Project Lead
- Tom Disley, Student Fellow
- Meg Drouhard, Student Fellow
- Vaughn Iverson, Data Scientist
- Jess Hamilton, Student Fellow
- Bryna Hazelton, Data Scientist
- Kaicheng Tan, Student Fellow
Will you please fill your user pages?
OpenSidewalks Website
Comments
Please comment on the discussion page.