Proposal:Deprecate cycleway=opposite family
| Deprecate cycleway=opposite family | |
|---|---|
| Proposal status: | Proposed (under way) |
| Proposed by: | Supaplex030 |
| Tagging: | cycleway=opposite cycleway=opposite_lane cycleway=opposite_share_busway cycleway=opposite_track |
| Applies to: | 
|
| Definition: | Deprecate the cycleway=opposite tagging family, as it is associated with logical problems and with oneway:bicycle=no we have a better and meanwhile much more widespread tagging used in OSM. |
| Draft started: | 2024-04-18 |
| RFC start: | 2024-05-21 |
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=no 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/suggest 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.
Since the alternative oneway:bicycle=no tagging has already been widely used for several years and is taken into account by virtually all evaluators/renderers/etc., the overall implications of this deprecation for data users are probably marginal. (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 in any situation by a corresponding tagging with the same meaning using a common oneway + cycleway combination. The following table gives examples for some cases.
Note: Since the simple cycleway=opposite is by far the most frequently used of all opposite tags (see below), in most cases it is sufficient to simply replace cycleway=opposite with cycleway:both=no and to make sure that oneway:bicycle=no is tagged on the street.
| Picture | Illustration | opposite tagging to be deprecated | Current oneway + cycleway tagging |
|---|---|---|---|
|
 |
oneway=yes |
|
|
 |
oneway=yes |
cycleway:right=no |
|
 |
oneway=yes |
oneway=yes cycleway:right=no |
[1] cycleway:left:oneway=-1 means that the cycleway on the left-hand side of the road (seen in the direction of the OSM line geometry) is used in the opposite direction to the direction of the line. In countries with right-hand traffic, this is the default assumption, so usually it's not explicitly tagged. According to the current documentation in the wiki, however, this implicit assumption should only be made for streets without oneway traffic. For oneway streets, in contrast, the default assumption is that cycleways run in the same direction as the line on both sides. A cycleway that leads against the oneway street should therefore be explicitly tagged with cycleway:<side>:oneway=-1 in order to ensure a clear interpretation of the data.
Current usage in the OSM database
(See also the chronology diagram above.)
Features/Pages affected
- Rework the cycleway=* page and the individual pages of the opposite tags to flag opposite tags as deprecated and recommend to not use them anymore.
- Rework all other pages on which cycleway tags are documented and on which opposite tags are mentioned (e.g. Bicycle) to only refer to the newer tagging variants without promoting opposite tags.
External discussions
- On the wiki talk pages Talk:Tag:cycleway=opposite and Talk:Key:oneway:bicycle, some discussions on the understanding of opposite tags and their relationship to oneway:bicycle=no have arisen in recent years.
- Discussion on problems with
cycleway:left=opposite_lane. - Discussion in the Netherlands forum which has led to a nationwide replacement of opposite tags and a de facto local deprecation in the Netherlands.
- The topic has also been mentioned again and again in other threads in the community forum, and it is clear that opposite tags lead to confusion or are simply regarded as a historical relic by most mappers.
- RFC announcements: Community Forum | Tagging Mailing List
Comments
Please comment on the discussion page.