Proposal:Deprecate cycleway=opposite family
| Deprecate cycleway=opposite family | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | Supaplex030 |
| Tagging: | cycleway=opposite cycleway=opposite_lane cycleway=opposite_share_busway cycleway=opposite_track |
| Applies to: | way |
| Definition: | Deprecate the opposite tagging family, as it is associated with problems and there is a better and meanwhile much more widespread tagging. |
| Draft started: | 2024-04-18 |
Proposal
This proposal aims to deprecate the cycleway=opposite tagging family, because
- this tagging family is associated with (logical) problems and
- meanwhile there is the much more widespread oneway:bicycle=* tagging allowing to map the same meaning in a better way.
The following tags are considered to be deprecated as part of this tagging family:
- cycleway=opposite,
- cycleway=opposite_lane,
- cycleway=opposite_share_busway,
- cycleway=opposite_track
- and all corresponding cycleway:side variants (cycleway:left=*, cycleway:right=* and cycleway:both=*).
Note: As no one can "forbid" the use of certain tags, deprecating in this sense means (see Deprecated features and Any tags you like):
- to discourage the use of cycleway*=opposite* more clearly than before (deprecation notices, documenting as outdated), so that (wiki) documentation no longer promotes this tagging and editors can be encouraged to no longer actively support this tagging in future,
- thus make visible that the majority of the community rejects its use and motivate all mappers to replace existing opposite tags with the current equivalents.
The proposal is not aiming at a (semi-)automated change of existing opposite values and does not consider this procedure to be useful in this case. However, manual mapping campaigns and challenges could help to replace existing opposite tags in the future.
Rationale
The cycleway=opposite tagging was first used in the early days of OSM to indicate one-way streets that can be legally used by bicycles in both directions. Over the last decade, it has been increasingly replaced by the more recent and more logical oneway:bicycle=* tagging (see chronology diagram), which is now used in parallel and far more frequently on those streets. This has essentially made opposite tagging obsolete.
opposite*values were invented in a time when using oneway:bicycle=* and suffixes for directions and sides were uncommon. But the tagging system evolved.— OSM Wiki: Key:cycleway - Problems with opposite* values.
Many mappers no longer use opposite tagging because it is associated with problems. Here is an overview of raised issues:
- Mixing infrastructure and access/direction:
- The intention of the cycleway=* key is to map bicycle infrastructure (in particular no infrastructure or lanes, tracks and shared_busways if present). However, opposite values are mixing infrastructure and access/direction informations, as they also make a statement about the direction of travel. cycleway=opposite is by far the most used tag within the opposite tagging family and does not even indicate any infrastructure, but only a direction of travel. The newer variant cycleway=no + oneway=yes + oneway:bicycle=no is very clear about this and leaves no room for interpretation.
- Logical problems if used with cycleway side suffixes:
- As a result of the mentioned issue, when using side suffixes in the cycleway=* key (cycleway:left/right/both=*), there is ambiguity which sides and directions opposite values are actually referring to, e.g. when using cycleway:left=opposite_lane. While the side suffixes solely states that there is some kind of infrastructure (or no infrastructure) on the referenced side seen in the direction of the OSM way geometry, opposite values are carrying a directional message related to an adjacent driving lane, although the driving direction of this lane can be different from it's geometries direction (e.g. oneway=-1 or even oneway=no). As a result of earlier discussions, it is already discouraged to use opposite values in combination with the increasingly used cycleway side suffixes in order to avoid this ambiguity.
- Vague regarding exact infrastructural situation:
- Thus, opposite tags remain rather unspecific regarding the exact infrastructural situation, in particular which sides provide which infrastructure and driving directions.
- Redundancy with cycleway=no/lane/share_busway/track + oneway:bicycle=no:
- The mentioned issues can easily be avoided by simply using regular cycleway=* tags (no, lane, track or share_busway) in combination with oneway:bicycle=no instead of opposite tags. This approach is now much more widespread, making the opposite values redundant and basically unnecessary.
- cycleway=opposite associates infrastructure where there is none:
- cycleway=opposite can be misinterpreted because there is no infrastructure, but a value other than no suggest an existing infrastructure at first glance. It is atypical not to use a no value although in fact it is meant.
- Exclusion of other transport modes:
- opposite tags are intended for statements about bicycles, but not for other modes of transport. However, a one-way street can also be open for other types of traffic in the opposite direction, e.g. mofas or mopeds. The opposite tags do not allow this access=* differentiation, whereas it can be easily tagged with the access variants of oneway (e.g. oneway:mofa=*, oneway:moped=*).
All in all, opposite tagging offers no advantages over the contemporary alternative, but does have a few disadvantages. If the more widespread tagging combination of common cycleway=* values and oneway=* tags is used instead, the result is logical tagging, which avoids misinterpretation. The replacement of the opposite tagging family would mean a simplification for everyone, mappers, editors and data users.
At local level, this tagging has already been deprecated; for example it has already been completely replaced by the Dutch community. (Note: As long as opposite tags are significantly present in the OSM database, editors and data users should continue to take care to evaluate these tags correctly).
Tagging and Examples
Each opposite* value can be replaced by a corresponding tagging with the same meaning in any situation and cycleway or oneway combination. The following table gives examples for the most common cases.
Replacement options with cycleway=* and oneway=* tags
| Picture | Illustration | opposite tagging to be deprecated | Current cycleway + oneway tagging |
|---|---|---|---|
|
ToDo | ||
|
ToDo |
oneway=yes | |
|
ToDo |
oneway=yes |
oneway=yes |
To be discussed: Are oneway tags/which oneway tags are implied? Check ohsome analyzer for combinations of oneway=yes + oneway:bicycle=no + cycleway:left=lane +/- cycleway:left:oneway=* (in right-hand traffic countries). Wiki documention explicitely mentions cycleway:left:oneway=-1 for contraflow lane, but not for contraflow share_busway. If it's used without cycleway:left:oneway=-1, I would argue it has considered implicit.
ToDo: How many streets are there actually with opposite tags, but without oneway:bicycle tags?
Meaning and interpretation of oneway on cycling infrastructure
ToDo
Current usage in the OSM database
(See also the chronology diagram above.)
Features/Pages affected
ToDo
External discussions
ToDo
Comments
Please comment on the discussion page.