Proposal:Advanced footway and cycleway
| Advanced footway and cycleway | |
|---|---|
| Proposal status: | Abandoned (inactive) |
| Proposed by: | Driver2 |
| Tagging: | cycleway/footway/path=both/left/right/none |
| Applies to: | Tags |
| Definition: | Define foot- and cycleways alongside the street. |
| Statistics: |
|
| Rendered as: | * |
| Draft started: | |
| Proposed on: | 2008-12-26 |
| RFC start: | 2008-12-26 |
| Vote start: | * |
| Vote end: | * |
Note: There is also a german translation of this proposal.
Summary
The current tagging scheme as stated on key:cycleway provides no method to define different types of cycleways on different sides of the street, nor is it possible to define a sidewalk that is both a designated cycleway and a footway. There are already proposed tagging schemes to map footways alongside the road (Proposed_features/Footway), but it is included here as well.
Please note that this Proposal does not try to solve anything more than the most simple cases of ways alongside a road. Any more complex cases should have their own way of tagging. Advanced only means that you have some more ways of tagging, not that it will cover everything.
Note: This is to tag foot- or cycleways at the side of streets. Ways that run physically (a wall, fence, wide meadow, bushes) separated, may be tagged as own ways with the approriate tags just like before.
Please jump to the examples, if you just want to get a first impression of how to use this.
Why do we need this anyway?
It can be useful for pedestrians or cyclists to know on which side of the road there are ways for them or if there are any at all. It may also be useful for routing applications to guide people not only over a street but also on one side of a street. Information about pavement use can also assist routing algorithms determine appropriate weighting for trunk roads.
Tagging
Define what kinds of ways there are
The main-keys can be used with the main-values to define what kinds of ways there are. For example cycleway=right for a cycleway on the right side of the street.
- Any of the main-keys are valid on their own, for example footway=right and cycleway=right only defines there are both types of ways on the right side, but not their relation to one another.
- A given key overwrites the default value of the same key. For example: highway=residential, footway=left defines a residential-road with only one sidewalk on the left. But only of the same key, another example: highway=residential, cycleway=left defines a residential-road with a cycleway on the left side, but also footways on both sides implied by residential. To only get the cycleway on the left side, you would have to tag: highway=residential, footway=right, cycleway=left.
- You should usually use ('footway' and/or 'cycleway') OR 'path'. path is optional if you want to express that e.g. a mixed foot- and cylceway run on the same physical way or if you just like path better.
- cycleway=right and footway=right means that there is either a mixed or a segregated foot- and cycleway. Either way, the important information is, that there is both. If you want to be more specific, you still can.
Alternative way to define what kind of ways there are
This proposal could also be made compatible to the right_left-Proposal.
| this (alternate way) | would equal to |
|---|---|
| footway=track | footway=both footway.type=track |
| footway:right=track | footway=right footway:right.type=track |
| footway:left=lane | footway=left footway:left.type=lane |
There would be, however, still be the issue of how to tag combined foot- and cycleways (track:right=..?) and what combinations of tags mean (footway:right=track, cycleway:right=track). Also, if default values are implied (like footway=track on residentials), something like footway=none would still be needed.
Define additional properties of the ways (like surface)
The second step can be (if necessary) to define properties of the given ways. This is particularly important with 'path', since it is neither a foot nor a cycleway by default. For example cycleway=right, cycleway.width=1.5 defines a cycleway on the righ side of the street with a width of 1.5 meters.
- Properties are given to the main-keys. In the case of a main-key being on 'both' sides, it may be necessary to define properties by side. The parameters 'left' and 'right' can be used for this. Example: highway=residential, footway:right.bicycle=yes, footway:right.surface=unpaved allows bicycles on the right unpaved sidewalk of a residential street (footway=both is implied by residential). The paramter 'both' is possible but usually not needed, since the missing of the parameter means that the properties apply to all instances of this main-key.
- Since the main-values replace the values from Key:cycleway (when using the first of the above two ways), we need another way to define whether the cycleway is on the sidewalk or a lane beside the road. If you want to define that, you can use the 'type' property. Example: cycleway.type=lane.
- The 'type' property defaults to 'track' if not specified.
Main-keys (types of ways)
| key | description |
|---|---|
| footway | A regular sidewalk with the same access-properties as highway=footway. |
| cycleway | A cycleway that either runs on the sidewalk or on a separate line beside the road, same access-properties as highway=cycleway. |
| path | Like path=* this is an optional way to tag combined foot- and cycleways (with foot=designated, bicycle=designated). |
Main-values
| value | description |
|---|---|
| right | The way runs somewhere on the right side of the road. |
| left | The way runs somewhere on the left side of the road. |
| both | The way runs somewhere on both sides of the road. |
| none | No way of this type is present. This is only needed if the highway-type implies some ways by default (for example residential roads having always sidewalks). |
Defaults (for highway-types)
These defaults could probably be also defined by country, if necessary.
Note: These are defaults proposed in this proposal only, other people might see this differently. Thus, it makes sense to always explicitly tag the occurence/absence of a footway=*. However cycleway=none as default seems sensible.
| highway | defaults to | reasoning |
|---|---|---|
| residential | footway=both cycleway=none |
Those streets very often have sidewalks, but usually no cycleway. Parts of the street out of town, that have no sidewalks should be tagged. |
| all other highway-types | footway=none cycleway=none |
Those ways usually have no sidewalks, because they are either too small or unimportant, or only for motorized vehicles. |
Examples
Some practical examples.
| Picture | Tagging | Comment |
|---|---|---|
|
highway=residential |
There's a normal sidewalk on the right side of the street and a line-separated foot/cycleway on the left side. Since they share the same way (even if segregated, but only by a painted line), they are tagged as one.
There has been some discussion if the foot/cycleway in this example is not too much separated from the street. But since you can cross the street at will at almost every point by foot or bicycle (due to the parking spots and the only small patch of grass), I don't think it should be drawn as a separate way. |
|
highway=residential |
There is a footway on both sides of the street, but also a lane for cyclists on the right side. Since the lane and the footway are on different parts of the road (separated by the kerb), also a separate tag is used. |
|
highway=tertiary |
Mixed cycleway/footway on the left side, cyclelane and footway on the right side. | |
|
footway=both is implied by highway=secondary, so we need footway=none to say there is none. | |
|
highway=residential | No further tags needed, since footway=both is already implied. However, it may still be sensible to explicitly tag footway=both. |
Consequences for editing software
Editors would have to warn the mappers when a way's direction is reversed or could even propose reversing the necessary tags automatically.
For this, they would have to be aware of:
- :left / :right somewhere in the key
- left / right as value (if you don't want to check all keys, just check those that start with 'cycleway', 'footway' or 'path')
All relevant tags should contain either of those, so it would be easy to detect them.
Some more thoughts about this proposal
About way-direction-dependent tags
Many people don't like things like 'left' or 'right' because they depend on the direction of the way. One of the arguments is, that changing the direction could break the tagging, if the editor doesn't warn the user about it. But it shouldn't be that hard to take care of a few keywords (left, right, forward, backward) when turning around ways and warn the user or even propose changing the tags automatically. But what if there's still an editor that doesn't support this? Well, what if there isn't an editor that doesn't take care of oneway=*? Being routed the wrong way in a oneway street should normally be equally bad as having the sidewalk on the wrong side. Ok, it should still be correct, but any tagging scheme that is not extremely simple will require editor support anyway. And most important: There hasn't been any simple suggestions to solve this that I am aware of just yet.
What about the 'old' cycleway-tags?
cycleway=track, cycleway=lane and so on can (of course) still be used, but can also be replaced by this proposal. They are not integrated in this proposal, since they are not clearly defined (they just say: "there is a cycleway", but not if it is on both sides or just on one side or whatever).
Why not integrate the 'type' in the main-tag?
It should be as easy as possible to tag and also to interpret the cycleway tags. If your renderer for example, is just interested in whether there is a cycleway, it can simply read out the cycleway-tag (and possibly the path-tag). If you want to have more information about the way, you can also take default-values and additional subtags like the 'type' into consideration.
The tagging should also be consistent with the already in use footway=left/right/both/none, but probably extents its definition a bit.
See also
- lane and lane group for a proposal for lanes using relations
- a bit of research into those proposals that currently touch the multilane-problem
- Old proposals: Proposed features/Sidewalk and Proposed features/Footway
Comments
Please use the talk page for discussion.