Proposed features/sidepath tagging scheme
|sidepath tagging scheme|
|Definition:||Looking for a possibility to tag a sidewalk/track/etc. as an adjacent way () AND as a tag on the main road-, giving Routers, Renderer and Mappers the opportunity to choose what they like best. Simultaneously looking for options to connect stand-alone to the main road-,without breaking the tagging scheme.|
|Rendered as:||Appearance will be up to the Renderer and possibly different for different zoom levels.|
This proposal is looking for a possibility to tag the information about a road adjacent sidepath (footway/cycleway/path) as data supplementing a main road (e.g. highway=residential + sidewalk=*) AND as a separate in the form of e.g highway=footway + footway=sidewalk. It also wants to find options for linking separate, stand-alone ways to the street and/or sidepath without breaking possible rendering and routing outputs or rather the tagging scheme witch this proposal wants to create.
- A sidewalk can be tagged as sidewalk=* on the street (e.g highway=residential) or as a separate OSM-way with highway=footway + footway=sidewalk at the moment. This also holds for cycleways in a similar way.
- Mappers may have problems, because there is are two contradicting ways for mapping sidepaths
- Renderer may have problems, because depending on the zoom level, it might be better to draw the way in regard to the main road way (lets say up to zoom level 16 ) or as a separated OSM-Way for a better representation of the foot ways position in regard to other object like trees, parking spaces, or on complicated junctions (lets say for zoom level 16 and higher).
- Routers may have problems, because positioning of the routing object on the street or footway / cycleway might be complicated or impossible due to imprecisions. In some cases it might be more useful to give routing instructions in a more general form (only directions along the main road way) or in a very detailed way, depending on the positioning accuracy. Also routing across a street might be more complicated, when using highway=footway instead of the main road.
- As the use of OSM data is very wide spread, only entering data for one specific use is problematic.
- Accepting a curb as a physical separation between a sidepath and the roadway is disputed. This has been the cause for many discussions and also edit wars, especially over road adjacent footways aka sidewalks.
- Distinction between road adjacent footways that are separated form the road way only by a curb and others ways separated by a ditch, fence, etc. might be interesting for some data consumers , e.g. routing programs.
- It is easier (at least in theory) to collapse multiple way onto a single one (as it's done by Skeletron than to guess the actual route of a sidepath (footway, cycleway) from thin air.
Right now, there are two contradicting ways of tagging a sidepath. The first one uses a tag on the main road to denote the sidepath ("near type"). This is most common when adding sidewalk to the database. The second one uses a new to denote the sidepath, mostly common when tagging cycle tracks ("far type").
The table below gives an example of the two tagging schemes. Please note that this also applies for different types of sidepaths (cycleways).
| (footway=sidewalk) |
| Default? |
Switching between the tagging schemes will only work when deleting one tag and adding the other. Also, as one may be aware, the tagging structure changes between different types of sidepaths (footway, cycleway) and in case of separately map ways also between differently tagged highway=path/footway/cycleway.
It is also common to collect all ways of a road, including possible separately drawn sidepaths, into a street-relation. In that case a sidepath could have the role "sidepath" to differentiate them from the central ways with the role "street".
This however doesn't derogate the need for an explicit tagging scheme as shown below, because adding/copying data for a sidepath to the central is at least very tricky, maybe even impossible. One would need to split a central way to match the length of a sidepath or copy the same data on multiple central ways. One would need to figure out on which side of the central way the sidepath is and how to handle dual carriage ways or multiple parallel sidepaths.
Some simple queries (like "show me all Streets in the street-Realtion the have a cycleway"):
- This proposal was going to use footway:right/left/both=sidewalk instead of sidewalk=right/left/both for symmetry reason and because footway:right/left/both=sidewalk would no longer be needed on highway=footways in this proposal. However sidewalk=right/left/both will be used (to make this proposal more acceptable).
- This Proposal is designed to be backward compatible, in the sense, that data consumers should not notice any changes from the current way of tagging.
The following tags (prefixes and values) listed and described in the table below represents the core of this proposal. The definitions and tag-names are what will be voted on.
|prefix||adjacent:*=*||Used on default sidepath tags (cycleway=*,sidewalk=*) on the central osm-way, when a sidepath (highway=cycleway,highway=footway,highway=path) is entered as a separately drawn osm-way (*=sidepath-type)||sidepath:|
|value||*=sidepath||Used to denote separately drawn sidepaths, where the central carriageway has adjacent:*=*-sidepath tags or no sidepath tags at all.||sideway, sidewalk, adjacent|
|prefix||sidepath:*=*||Used to denote separately drawn sidepaths, where the central carriageway has default sidepath tags (cycleway=*,sidewalk=*) on the central osm-way.||sideway:, sidewalk:, adjacent:|
|value||*=connector||Denotes a connection (highway=cycleway/footway/path) between a sidepath:*=*-type sidepath and the carriageway (highway="roadtype"), where a stand-alone highway=*-way branches off and no crossing (*=crossing) is present||link|
|prefix||connector:*=*||Denotes a connection between a *=sidepath-type sidepath and the carriageway (highway="roadtype"), where a stand-alone highway=*-way branches off from a *=sidepath-type sidepath and because of that doesn't have a direct connection to the carriageway (separated by grass, curb, fence, etc.)||link:|
|value||*=crossing||Denotes a connecting way (highway=cycleway/footway/path between a *=sidepath-type sidepath and the carriageway that is part of a crossing.|
|prefix||crossing:*=*||Denotes a connecting way (highway=cycleway/footway/path between a sidepath:*=*-type sidepath and the carriageway (highway="roadtype"), that is part of a crossing and does not have a stand-alone way branching off from the carriageway|
To help describe different situations in the example part, the tagging possibilities and options are divided into 6 (8) segments with 4 (5) distinct tagging options.
- near : Situation in which sidepaths are separated from the carriageway by a curb only.
- far : Situation in which sidepaths are separated from the carriageway by a grass strip, ditch, etc.
- compressed : Tags on a separately drawn osm ways are going to get a prefix. Tags on the main way will be the classic ones.
- detailed : A separately drawn osm ways will get a classic tagging and an additional sidepath tag. Tags on the main way are going to get a prefix.
- mixed: Uses both compressed and detailed tagging style. Tags for near sidepaths will be in the compressed style, Tags for a far sidepath will be in the far style.
| adjacent:cycleway:right/left/both=track |
| highway=cycleway/footway/path |
|Detailed||roadway|| adjacent:cycleway:right/left/both=track |
|sidepath|| highway=cycleway/footway/path |
footway and cycleway
|roadway|| adjacent:cycleway:right/left/both=track |
|sidepath - footway|| highway=footway |
|sidepath - cycleway|| highway=cycleway |
This example will use both types of tagging (compressed and detailed) on an imaginary landscape, that incorporated many different situations from which allot more can be derived hopefully. It's the more complicated type of tagging but allows for the most diverse tagging.
Translated into osm-ways, this is how it would look like in JOSM Wireframe sketch up.
As one can imagine, the tagging of the sidepaths itself is less problematic than handling the links between the sidepath and the street, and the crossings.
- Styles are name with the default-osm-carto style and the opencyclemap-style in mind.
- Detailed : Footways are rendered as separate osm-ways
- Mixed : Near footways are rendered as part of the main road-way, while far footways are rendered as separate osm-ways.
- Compressed : Road adjacent footways are rendered as part of the main road-way.
The above tagging scheme allows to render sidewalks in various ways as shown in the Query Table below:
|Style||Rendering||Near Type||Combined Type||Far Type|
| sidewalk=* or adjacent:sidewalk=*
(highway=footway and not footway=sidepath) or connector:highway=footway
(highway=footway and not footway=sidepath) or connector:highway=footway
|Mixed||Not Possible|| Default
|Detailed||(highway=footway and not footway=connector) or (sidepath:highway=footway or crossing:highway=footway)||(highway=footway and not (footway=connector or sidepath:highway=footway)) or (sidepath:highway=footway or crossing:highway=footway)|| Default |
Sorry, but most of them are in German since I follow the German forum primarily.
- 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
- Tagging - Sidewalks vs Footways
Related Wiki Pages
Please comment on the discussion page