Proposal:Make cycleway:both the default to indicate both sides: Difference between revisions

From OpenStreetMap Wiki
Jump to navigation Jump to search
(→‎Looking at some Editors: Link to westnordost's details on how StreetComplete handels the tags)
(Update proposal to clarify that cycleway=* is not redefined; try to describe the current (most used) definition.)
Line 18: Line 18:
Make {{Tag|cycleway:both}} the recommended default on highways to indicate that the value applies to both sides of a way. The recommendation should be followed when the mapper is able to clearly specify the bicycle infrastructure for both sides.
Make {{Tag|cycleway:both}} the recommended default on highways to indicate that the value applies to both sides of a way. The recommendation should be followed when the mapper is able to clearly specify the bicycle infrastructure for both sides.


The definition of {{Tag|cycleway}} is not changed by this proposal.
New {{Tag|cycleway}} tags should be considered as unspecific regarding the side of the infrastructure.


This change only applies to values usually applied to one or more sides of a highway. Values like {{Tag|cycleway|crossing}} will continue to use the tag without any side subkey.
This change only applies to values usually applied to one or more sides of a highway. Values like {{Tag|cycleway|crossing}} will continue to use the tag without any side subkey.
Line 24: Line 24:
==Rationale==
==Rationale==


The tagging of separate values for each side of a way is well established with side subkeys like {{Tag|cycleway:left}} and {{Tag|cycleway:right}}. However, the tagging that indicates both sides of a way is less clear for historic reasons. This leaves mappers and data consumers in a situation where the definition of {{Tag|cycleway}} (no side subkey) is unclear:
The tagging of separate values for each side of a way is well established with side subkeys like {{Tag|cycleway:left}} and {{Tag|cycleway:right}}. However, the tagging of bicycle infrastructure that is present on both sides of a way is less clear. This leaves mappers and data consumers in a situation where the definition of {{Tag|cycleway}} (no side subkey) is unclear:


* It could mean "a cycleway somewhere on the way."
* It could mean "a cycleway somewhere on the way."
* It could mean "a cycleway on the primary direction of the way", e.g., on the right in many countries or when used on a dual carriageway.
* It could mean "a cycleway on the primary direction of the way" with special treatment for cases like dual carriageway, oneway streets and/or {{Tag|oneway|-1}} streets and based on the country (left-/right-hand-traffic).
* It could mean "a cycleway on both sides of the way."
* It could mean "a cycleway on both sides of the way."


The status quo leaves us with different interpretations on how to treat {{Tag|cycleway}}.
The first two definitions are more historic, from a time when OSM had less precise data. They are also still be used today when mappers cannot add more detailed tagging due to a lack of time or tooling at that precise moment.


Therefore, we should make an effort to migrate {{Tag|cycleway}} to {{Tag|cycleway:both}} or its corresponding left and right tags to clarify the bicycle infrastructure.
The last definition is somewhat enforced by modern editors that show the key in a UI that makes it explicit that the value applies to both sides, like iD and Rapid do.


This proposal does not seek to change the current definition of the tag, but rather to outline the existing interpretations.
This unclear definition causes issues with tagging presets and tag updates because the two tags (with and without a side subkey) cannot confidently be considered the same and an unclear definition on how to interpret {{Tag|cycleway}}.

Therefore, we should make an effort to migrate the {{Tag|cycleway}} to {{Tag|cycleway:both}} or its corresponding left and right tags to clarify the bicycle infrastructure.

This proposal does not speak against using iterative tagging (first tag {{Tag|cycleway}} and later add details by adding side tags).
==Current Usage==
==Current Usage==


Line 74: Line 70:
'''1.464.887 ways'''<!-- 1342256+27019+64212+11607+18935+858-->
'''1.464.887 ways'''<!-- 1342256+27019+64212+11607+18935+858-->
|[https://taghistory.raifer.tech/#***/cycleway%3Aboth/no&***/cycleway/no&***/cycleway%3Aboth/separate&***/cycleway/separate&***/cycleway%3Aboth/lane&***/cycleway/lane&***/cycleway%3Aboth/track&***/cycleway/track%20&***/cycleway%3Aboth/shared_lane&***/cycleway/shared_lane%20&***/cycleway%3Aboth/share_busway&***/cycleway/share_busway Usage Graph]
|[https://taghistory.raifer.tech/#***/cycleway%3Aboth/no&***/cycleway/no&***/cycleway%3Aboth/separate&***/cycleway/separate&***/cycleway%3Aboth/lane&***/cycleway/lane&***/cycleway%3Aboth/track&***/cycleway/track%20&***/cycleway%3Aboth/shared_lane&***/cycleway/shared_lane%20&***/cycleway%3Aboth/share_busway&***/cycleway/share_busway Usage Graph]
|The total numbers show the <code>:both</code> variant has the most usage overall but those number differ per valu
|The total numbers show the <code>:both</code> variant has the most usage overall but those number differ per value.
The rows below look into each value and their grows trajectory in recent years.
The rows below look into each value and their grows trajectory in recent years.
|-
|-
Line 157: Line 153:


==Definition ==
==Definition ==

There are still cases for using [[Key:cycleway]] on highways in our daily mapping practise. Which can now be more clearly defined:
{| class="wikitable"
{| class="wikitable"
|+
|+
Line 168: Line 162:
|-
|-
|<code>cycleway=*</code>
|<code>cycleway=*</code>
|''This proposal does not seek to change the current definition of the tag. However it is helpful to clarify the most common interpretation that can be distilled from the discussion around this proposal:''The given bicycle infrastructure is present on the customary direction of the way.
|The given bicycle infrastructure is present somewhere on the road. It might be the left, right or both sides.

It is recommended to migrate this tagging to be explicit about sides over time.
* For a typical two lane forward/backward road, that would be bicycle infrastructure on both sides.
* For a <code>oneway=yes</code> road, that would be bicycle infrastructure on the customary direction of the road. (Given that no other tags say otherwise.)

|}
|}


Line 180: Line 177:
'''Editors:'''
'''Editors:'''


*Ask OSM editors to use the <code>:both</code> version whenever they provide an Interface to users that allows to clearly specify the cycleway for both sides. Examples of this would be iD and StreetComplete. Ideally those editors will recognize both version but use the <code>:both</code> version when tags are added or modified, providing a soft migration path to the more precise tag.
*Ask OSM editors to use the <code>:both</code> version whenever they provide an Interface to users that allows to clearly specify the cycleway for both sides. Examples of this would be iD, Rapid and StreetComplete. Ideally those editors will recognize both version but use the <code>:both</code> version when tags are added or modified, providing a soft migration path to the more precise tag.
*Ask OSM editors to consider adding feature that would allow for a faster update path to the more precise tag. An Example of this would be a tag update notice in the iD.
*Ask OSM editors to consider adding feature that would allow for a faster update path to the more precise tag. An Example of this would be a tag update notice in the iD.
'''Rendering:'''
'''Rendering:'''


* Common rendering already supports both tag variations. However they might not all follow the same interpretation when combined with oneway=yes<ref>https://community.openstreetmap.org/t/rfc-feature-proposal-make-cycleway-both-the-default-to-indicate-both-sides/116585/31</ref> and edge cases like oneway=-1<ref>https://community.openstreetmap.org/t/rfc-feature-proposal-make-cycleway-both-the-default-to-indicate-both-sides/116585/27</ref> that are related to this.
* Common rendering already supports both tag variations. At some point when usage numbers change, the visualization of [[Key:cycleway]] might change as well.


==External discussions==
==External discussions==
Line 191: Line 188:
*It was also inspired by work on the [[FixMyCity GmbH/Radverkehrsatlas|Radverkehrsatlas]] project.
*It was also inspired by work on the [[FixMyCity GmbH/Radverkehrsatlas|Radverkehrsatlas]] project.
*There was some discussion on an id-tagging-schema issue: https://github.com/openstreetmap/id-tagging-schema/issues/1025.
*There was some discussion on an id-tagging-schema issue: https://github.com/openstreetmap/id-tagging-schema/issues/1025.
*There is a detailed discussion [https://community.openstreetmap.org/t/rfc-feature-proposal-make-cycleway-both-the-default-to-indicate-both-sides/116585/27 in the RFC Thread] in the forum.


==Comments==
==Comments==

Revision as of 13:38, 9 August 2024

Make cycleway:both=* the default to indicate both sides
Proposal status: Draft (under way)
Proposed by: tordans
Tagging: cycleway:both=*
Applies to: way
Definition: Make cycleway:both=* the recommended default to indicate that the value applies to both sides.
Statistics:

Draft started: 2024-06-30

Proposal

Make cycleway:both=* the recommended default on highways to indicate that the value applies to both sides of a way. The recommendation should be followed when the mapper is able to clearly specify the bicycle infrastructure for both sides.

The definition of cycleway=* is not changed by this proposal.

This change only applies to values usually applied to one or more sides of a highway. Values like cycleway=crossing will continue to use the tag without any side subkey.

Rationale

The tagging of separate values for each side of a way is well established with side subkeys like cycleway:left=* and cycleway:right=*. However, the tagging of bicycle infrastructure that is present on both sides of a way is less clear. This leaves mappers and data consumers in a situation where the definition of cycleway=* (no side subkey) is unclear:

  • It could mean "a cycleway somewhere on the way."
  • It could mean "a cycleway on the primary direction of the way" with special treatment for cases like dual carriageway, oneway streets and/or oneway=-1 streets and based on the country (left-/right-hand-traffic).
  • It could mean "a cycleway on both sides of the way."

The status quo leaves us with different interpretations on how to treat cycleway=*.

Therefore, we should make an effort to migrate cycleway=* to cycleway:both=* or its corresponding left and right tags to clarify the bicycle infrastructure.

This proposal does not seek to change the current definition of the tag, but rather to outline the existing interpretations.

Current Usage

Looking at some Editors

  • StreetComplete treats the cycleway tag as the same as cycleway:both but tags cycleway:both. There are additional conditions for oneway=no and oneway=-1 which westnordost explains in his forum comment.
  • iD Editor only supports cycleway and hides all data tagged as cycleway:both. It presents the cycleway tag in a UI that shows it as left/right and merges left/right values into cycleway if the same values are tagged.

This discrepancy between StreetComplete and iD alone is why it is worth improving the current tagging recommendations.

Looking at the Wiki

  • The wiki page Key:cycleway does not discuss sides in detail and does not mention the issue described here.
  • The wiki page Key:cycleway:both discusses the ambiguity of cycleway.

Looking at numbers

Please keep in mind that those numbers can only be a signal for our opinion forming process.

They are heavily influenced by historic usage and editor presets.

  • Historically the Key:cycleway was used. Usage of the Key:cycleway:both started around 2018 (Usage Graph). This favors the Key:cycleway in total numbers.
  • StreetComplete is likely the driver behind a high number and increase of the cycleway:both=no value. This favors this key and the :both variant in general in total numbers.
  • iD Editor: iD on the other hand only shows and tags the cycleway=* tag, even though mappers make a explicit choice per side. This favors the cycleway=* tags in total number even in recent years.

Of those distorting factors only the historic usage can easily be worked around by looking at usage in recent years in the usage graphs. More on that in the "Note" column below.

Value cycleway=… (Taginfo) cycleway:both=… (Taginfo) Graph Note
Sum for no/ separate/ lane/ track/ shared_lane/ share_busway 2024-07:

781.319 ways

2024-07:

1.464.887 ways

Usage Graph The total numbers show the :both variant has the most usage overall but those number differ per value.

The rows below look into each value and their grows trajectory in recent years.

no 2024-07-01:

296.789 ways

2024-07-01:

1.342.256 ways

Usage Graph The graph strong increase of :both after 2021
separate 2024-07-01:

22.159 ways

2024-07-01:

27.019 ways

Usage Graph The graph shows more :both since end of 2023.

Please note that in the case of "separate," left/right indications are also an important piece of information for data analyses, data processing, and validation tasks and should therefore always be included.

lane 2024-07-01:

307.870 ways

2024-07-01:

64.212 ways

Usage Graph cycleway=lane dropped mid 2022 and did not grow relevantly since then.

The :both has less usage but shows a clear grows trajectory.

track 2024-07-01:

73.770 ways

2024-07-01:

11.607 ways

Usage Graph cycleway=track is dropping continously since 2018.

The :both has less usage but shows a clear grows trajectory.

shared_lane 2024-07-01:

76.652 ways

2024-07-01:

18.935 ways

Usage Graph The graph shows both variants show a grows path with the non-both-variante having higher numbers.
share_busway 2024-07-23:

4.079 ways

2024-07-23:

858 ways

Usage Graph cycleway=share_busway is a flat line since 2018 with a big jump in 2022.

The :both has less usage but shows a clear grows trajectory.

Values without a left/right concept
crossing 2024-07-01:

149.498 ways

2024-07-01:

0 ways

Crossing does have concept of left/right, which is why it will continue to use the cycleway=crossing tag.
(and others…)

Also keep in mind that given that the cycleway-key is used for tags like cycleway=crossing and cycleway=asl we cannot compare numbers on key-level but have to sum them manually.

The wiki page on cycleway:both has a bit of history on the tag:

The tag has been in use since 2010.

Its usage has significantly increased in 2017 when it became used by StreetComplete which started asking about cycleways(…).

Definition

Key Defintion
cycleway:both=* The given bicycle infrastructure is present on both sides of the road.
cycleway=* This proposal does not seek to change the current definition of the tag. However it is helpful to clarify the most common interpretation that can be distilled from the discussion around this proposal:The given bicycle infrastructure is present on the customary direction of the way.
  • For a typical two lane forward/backward road, that would be bicycle infrastructure on both sides.
  • For a oneway=yes road, that would be bicycle infrastructure on the customary direction of the road. (Given that no other tags say otherwise.)

Consequences

Documentation:

Editors:

  • Ask OSM editors to use the :both version whenever they provide an Interface to users that allows to clearly specify the cycleway for both sides. Examples of this would be iD, Rapid and StreetComplete. Ideally those editors will recognize both version but use the :both version when tags are added or modified, providing a soft migration path to the more precise tag.
  • Ask OSM editors to consider adding feature that would allow for a faster update path to the more precise tag. An Example of this would be a tag update notice in the iD.

Rendering:

  • Common rendering already supports both tag variations. However they might not all follow the same interpretation when combined with oneway=yes[1] and edge cases like oneway=-1[2] that are related to this.

External discussions

Comments

Please comment on the community forum page.