[RFC] Feature Proposal - Make cycleway:both the default to indicate both sides

General talk Tagging general discussion
, , ,
21

Such an opinion always gives me bad feelings…

22

Another way to look at it could be to say that it is approximate mapping similarly to highway=road.

3 Likes
23

There’s two arguments against that:

  • I’d rather have an experienced mapper have to switch tags than a novice one not being able to figure which one to use or how to use it.
  • Whether you need to switch tag (aka key), switch value or add a tag (key/value-pair) to get more specific really doesn’t make much difference in any editor that I’m aware off. All editors that I know of (and at least iD, JOSM) where you can edit tags directly, you can edit either the key and the value equally easy.

There’s always a trade-off between userfriendliness and completeness. But in case of :both it seems a false sense of completeness to me, as the lack of the :left- or :right-posfix defaults to the same meaning as :both. So it’s no different then adding oneway=no to a highway=* where this is already the default.

24

Hey! I feel like the discussion is getting of track a bit. I tried to find a wording for the proposal that makes it clear, that we change our recommendations on how to map bicycle infrastructure to be more explicit in terms of sides. It is not my intention to deprecate or disallow or in any way prevent mappers from using the non prefixed version for cases that they think are appropriate.

Right now, we are in a situation where different understandings of the cycleway=* variant exist (some situational / context dependent). My goal is, to clarify that we should – whenever possible – use the cycleway:both=* variant.

An example of a case where this would be possible regularly is when mapping with Presets like iD and Rapid offer to users.

I don’t see any issue in mappers still using the cycleway=* as a tagging of their choosing in situation where they think that it fits the situation better. For example the case where a gradual mapping of a track is chosen that @Richard described. And I don’t think the proposal does prevent / disallow or comment on this kind of mapping.

I went over the proposal yesterday with the goal to clarify this.

Please let me know which parts of the proposal you consider unclear and how to improve it.

1 Like
25

Thank you for taking the time to write the next version of your proposal.

Questions unanswered

While this might be true (this is in the eye of the beholder), there’s still - at least for me, a major question (that is on track) unanswered. As I wrote before:

My further motivation for my objections also remains unanswered - and unaddressed by the change in the proposal.

Wording

Your wording here suggests that this has been always your intention, while the change clearly shows that the proposal originally talked of deprecating.

I’ll give you the benefit of the doubt that this suggestion came to be due to language barrier, but it’s a form of gaslighting and doesn’t come across pretty either way.

Selective representation of statistics

Other feedback to the RFC, that has been given prior and not addressed:

The OSM Tag History for cycleway=no and cycleway:both=no shows that the :both variant is used much more.

As stated before: I object to this. It should compare the generic usage of cycleway= vs cycleway:both=, not just one value, as that skews the statistics significantly in the advantage of your proposal.

This goes to show that it really is a selective representation of the numbers. This is further illustrated by the stats in your proposal where =no, together with =separate are the only two values where cycleway:both= has more usage then cycleway=.

Again, skewing the representation of the facts.

A fair representation, to my mind, would be:

The OSM Tag History for cycleway= and cycleway:both= shows that the :both variant is in use more. This difference is largely explained by the difference in usage between cycleway=no and cycleway:both=no, where cycleway:both=no has recently overtook cycleway=no.
This is also the case for cycleway:both=separate too. For all other values cycleway= is used more then cycleway:both=."

You have my permission to use that for your propsal if you like. :wink:

Introducing confusion

This now actually introduces the confusion that you say exists, but have yet to present proof for.

1 Like
26

Thanks for taking the time to collect your objections in one post, @roelant.

On the topic of statistics:

Total numbers are not a requirement for an improvement in tagging. I consider them a signal that we should include in our opinion forming process.

I reworked the “Current usage” section today to go into more details on how the numbers are influenced by history and editor presets.

Thanks for the nudge to rework this section!

I hope it does a better job now at explaining the status quo and the main influencing factors that we need to remember when looking at the numbers.

Please help me understand what proof you are looking for, that is not linked in the proposal or referenced in this thread.

In addition to this, historically, tags in OSM were defined less precisely and used more loosely. Data was not collected at the same level of detail as we do today.

All of those comments confirm to me that cycleway cannot be safely assumed to reference both sides.

The next question will be if this imprecision is an issue. AFAIK renderers and routers treat cycleway=* as a tag for both sides, for example. However, I consider this a workaround that they have to make, because what else should they do, given the data they receive.

Projects that I am involved with – some of them as part of the OSM Verkehrswende User Group – will benefit greatly from a more explicit tagging of data. For example the cycle quality indes project and the Radverkehrsatlas that processes OSM data to help administration staff to build bike infrastructure (there will be a short introduction available once the recording of my talk at the SOTM EU is released).

The main thing I am trying to resolve is the mismatch between StreetComplete and iD. And the cleanest way to do this, IMO, is to change the recommendation on which key to use when infrastructure is tagged on both sides.

2 Likes
27

Citing the proposal text

  • StreetComplete treats the cycleway tag as the same as cycleway:both but tags cycleway:both.

Small correction here: This is generally true, but for oneways, a cycleway without explicit side needs some special handling. E.g. a cycleway=track is interpeted as…

  • …in countries with right-hand-traffic…
    • …for oneway=yes: cycleway:right=track
    • …for oneway=-1: cycleway:left=track
  • … in countries with left-hand-traffic…
    • …for oneway=yes: cycleway:left=track
    • …for oneway=-1: cycleway:right=track
  • otherwise: cycleway:both=track

i.e. each the other side is interpreted as “not defined” / “ambiguous” / “none?”.

(I guess, even smarter data consumers could look at whether oneway:bicycle is yes and divine from that whether the track in that case is more likely to be meant to be on both sides, but uh… well, it’s guesswork, and for SC we don’t want to guess but find gaps in data and fill them so that data consumers don’t need to.

This alone is a reason for me to always tag the cycleway explicitly for each side when surveying.)

2 Likes
28

cycleway=* is already entirely clear. It means that, throughout the entire Way, there exists cycleway provision within the side(s) of the road present within the way, unless stated otherwise by something more detailed.

Similarly:

  • max_speed=* means the max speed applicable to the side(s) of the road present within the Way, unless stated otherwise by something more detailed.
  • surface=* means the surface applicable to the side(s) of the road present within the Way, unless stated otherwise by something more detailed.
  • etc.

If we are to be adding a :both prefix to cycleway, that logically should similarly be done with every other tag. There is nothing special about a cycleway being on both sides vs speed or surface or whatever.

In fact, cycleway:both=* as a default would make things worse. It would strongly imply a total lack of ambiguity that this applies to both sides, to the extent that someone has gone and surveyed things and positively confirmed this in the presence of doubt. That makes it highly inappropriate to be a default. If existing tools are doing this, they should not be. Such specificity implies a far stronger level of confidence than is likely.

There really is no problem being solved with this change. The current default is correct and entirely clear, and exceptions also have clear tagging available.

3 Likes
29

Well, there is a structural difference: maxspeed and surface are properties of the road line itself, and in the vast majority of cases they are not directional. Where they are, we have the forward/backward scheme to specify this. If forward or backward tags are missing, however, there is no room for interpretation - when interpreting the data in cases such as one-way streets, dual carriageways, etc., there is no need to “guess” what the information is supposed to mean.

A cycle path, on the other hand, is always on one side of the road, either on the left or right (or both). This is a characteristic of all roadside phenomena, due to the approach we use to capture them in OSM (i.e. based on a centerline). Unfortunately, for historical reasons, we deal differently with this fact:

  • For sidewalks, we specify the side as a value (sidewalk=left/right/both/no). An unspecific sidewalk=yes is almost never used (0.17% of all cases). Alternatively, we use the side specification as a suffix to the key (sidewalk:left, sidewalk:right, sidewalk:both), especially for separately mapped sidewalks.
  • Similarly for shoulder, although a non-specific “shoulder=yes” is more common here than for sidewalks (9%) - perhaps because this is often an attribute of dual carriageways/motorways, where it refers to the “outer” side of the road (right in countries with right-hand traffic).
  • For street parking (a newer tagging scheme that was able to learn from previous experience), the side attributes are an integral part of the key (parking:right, parking:left, parking:both). There are almost no roadside parking tags without a side attribute.
  • verge is only rarely used, but usually contains a specific side attribute in the value (in 10% of cases it does not).

From this point of view, cycleways are the only roadside system modeled on the centerline for which there is an accepted (albeit increasingly rare) significant tagging variant without a specific side indication.

The proposal discussed here is not about “deprecating” cycleway without a side information, but merely about motivating mappers and editors more strongly to include an obvious attribute of such ways in order to reduce ambiguities in the data and to achieve a significant benefit for their interpretation and evaluation. cycleway without a side suffix is still fine, but it remains what it already is: vague. In my opinion, the use of side suffixes is therefore the better choice in every possible case.

4 Likes
30

(I’ve now also read the proposal text. I wanted to post this in the discussion page but read that you prefer to have feedback here. I feel discussing it in the forum is usually less focused and productive due to the format. (No threads in the forum, no issue-oriented feedback, i.e. per-topic), but anyway, as you wish)

The current proposal text already has my vote, but here are some comments that may lead to more people approving of the proposal:

1. long proposal text for small change

The proposal reads a bit long-winded and complicated. It is just about recommending to use cycleway:both when users want to explicitly specify that indeed both sides are the same, yes?

I’d recommend at least cutting the Looking at numbers section short, just add a graphic from taghistory (and annotate it with some labels, if necessary).

2. tag definition

From the discussion in this topic so far, I take that some strongly disagree with the notion that cycleway means

cycleway=* - The given bicycle infrastructure is present somewhere on the road. It might be the left, right or both sides.

(emphasis mine)

…because they have been using this tag for decades and might even feel like this text might be like a redefinition. I’d recommend softening this wording, degrading cycleway to something alike highway=road (as I’ve read having been mentioned in this thread) seems to overshoot the target.

It might be enough to mention cycleway is not explicit about for which side the cycleway is meant, but usually it can be assumed that it is meant for both sides except in the case I mentioned.

3. editor support

The greatest part of what you would like to solve with this proposal seems to be (approval for) a new feature request for iD - to properly support cycleway:<side> alongside cycleway and not just hide one of these tags if the other is present. TBH, that seems almost like a bug in iD. Maybe what is needed is rather someone to properly implement that.
(OK but I understand that the issue remains what such implementation should tag in case both sides are specified to be the same - cycleway:both or cycleway. At least one person in this thread seemed to not have been happy about that StreetComplete tags the sides explicitly if the user explicitly specified each side in the UI)

2 Likes
31

There are some other examples that have not been mentioned yet. For example, some data consumers have different interpretations of oneway=yes + cycleway=*.

This creates a lot of confusion and causes some people to insist that their interpretation is correct, but in reality it’s just a mess.

For example:
• StreetComplete assumes that oneway=yes + cycleway=* means the cycleway is only on the main side
• CycleOSM assumes that oneway=yes + cycleway=* means the cycleway is on both sides

Because of this confusion, it would great to encourage cycleway:both over cycleway

2 Likes
32

This creates a lot of confusion

Yes, I think using consequently cycleway:both solves the problem.

These are only assumptions in the case of unclear mapping. How can one insists on one of that interpretations?
The maps do not make the rules how to map.(do not map for a renderer)
The valid documentation should to be found in the wiki. Is there an interpretation in case of oneway documented? And was it discussed before?

33

Thanks for your continued work on this, again. I do understand it’s not an easy task to do such a proposal, and discussions like this can feel tedious. I hope we can all recognise that this is over passion of getting it right, for a better map. I appreciate your continuation of addressing my concerns and that of others and hope to return the favour by carefully replying.

Statistics

Yes and no: you present the statistics in a way that implies they are an argument to implement the change. In return, you cannot expect others to ignore other statistics that argue against it and present those similarly. :slightly_smiling_face:

I appreciate that. I still believe it could do with further improvement, but in the end it’s your proposal and this is a big step forward, thank you.

And you’re welcome, of course. :blush:

Proof: citation needed?

The long and short of it is best explained by Citation Needed - which is quite a common thing on WikiPedia. The the article jokingly explains this by providing an example quote: “87 percent of statistics are made up on the spot [citation needed]”. We’ve probably all seen the real thing, too.

While this quote is about statistics, the same can apply to argumentation. It’s very easy to write something, such as: “[some people say that] white elephants are actually pink” and then use that as fact, while it actually isn’t. The proof would be in seeing this pink white elephant. In this specific case, the quote that needs citation to my mind, would be “This leaves mappers and data consumers in a situation where the definition of cycleway=* (no side subkey) is unclear”.

Just to be clear, I don’t expect everything on the OSM wiki to be referenced to the same degree and solidity as WikiPedia or a scientific paper. Though I’m not saying that would be a bad thing either, because it wouldn’t hurt, but the OSM wiki has a different purpose which I do believe allows lowering the bar.

Given however that in the case of this proposal these statements are the key driver and argument for the proposal, I believe that it is fair to expect a little more in terms of fact and proof from these statements. Until such time, they’re more of a working hypothesis.

For instance, your write:

This is at odds with what your original statement (“This leaves (…) data consumers in a situation where the definition of cycleway=* is unclear”). It seems to me that it’s actually quite clear, they act accordingly, it’s just that you don’t agree with this.

To explain that both more based on your first argument:

In terms of proof, to my mind is the equivalent of someone creating a website stating that “87 percent of statistics are made up on the spot” and then somewhere else on the internet someone claims this and points to that website as proof, while the website actually doesn’t have any proof to begin with.

Neither your statement nor the wiki-page this argument refers to has proof, in terms of actual data consumers not sure how to interpret the values. You actually present an argument against it, as pointed out above.

The argument presented on the referred wiki-page is also flawed, because the reasons provided for it being “sometimes not true or ambiguous” are:

Note for example cycleway=opposite_lane, or use of cycleway=track where track is only on one side.

The opposite_lane value was recently deprecated, among other things because of the problems this tag created in this respect. And the problem as described with cycleway=track can be interpreted in more then one way. For instances that the problem is that it should be tagged with cycleway:left or cycleway:right, instead of just cycleway. Then, the problem would be inaccurate tagging and not that the cycleway-tag itself is the problem.

This is also suggested on cycleway=lane:

Some people suggest that such tagging is clearer than cycleway=lane, because many taggings exist where cycleway=lane was used where only one side of road has a cycleway lane.

And I wonder: isn’t it very likely to be an edge case? Looking at the statistics for this tag:

In that context:

(and it actually looks like a bunch actually got converted from the second to the first in a short period of time, judging by the jump in both graphs at the same time btw).

So from that 308.528 that have the generic cycleway=lane tag, how likely is it that the majority of that is wrong, is actually be just on one side and should’ve been tagged :left or :right where it isn’t already done so? Or is it actually correct to assume that the majority is indeed on both sides? Please hold this thought, for when I go into the ID GUI below.

On top of that, I can only speak based on experienced with Dutch infrastructure (and probably just a small part of it) that it’s an exception where there’s only a lane on one side and not on the other, which would imply that at least in the Netherlands, the majority of those must actually be right for both lanes. But I admit not having looked into the statistics to verify that (and wouldn’t know how tbh, other then by random samples).

In other words, the question I’m trying to raise, is: how big a problem is this, and does it justify making the majority (where assuming cycleway= represents both sides presumably actually is correct) suddenly inaccurate by changing the interpretation/documentation? Or should the the few that are inaccurate just be corrected (as so often happens with other tags)?

But bringing that back to your example of renderers and routers, I don’t think it’s unfair to also ask which assumption is “more wrong”:

  • The current one: assuming that cycleway= means both sides unless specifically specified otherwise, or
  • Your proposed version: assuming that cycleway= does not mean both sides unless the :both-postfix is added, but it is unclear what is.

If I were a betting man, I’d go for the last.

Again, it has quotes, but it doesn’t provide actual real world examples, or proof that this is the majority of applied tags, instead of a minority or even an edge case.

But isn’t also, in part, already resolved by introducing :right and :left? This allows to get more specific where applicable, without having to consider the previous data inaccurate per sé.

Editor vs. Editor

Alright, but there’s two things at play here: the GUI and the stats (yes, again).

1: ID GUI and implications of that GUI

Just to make sure we’re on the same page her,e if you add a cycleway trough the UI, it by default it offers both, and will add those trough the :left and :right postfixes respectively if different and only when both are actively specified as the same, the cycleway= tag without addition is used:

Adding bike lanes
Adding bike lanes764×202 16.3 KB

Editing bike lanes
Editing bike lanes746×214 6.69 KB

Different bike lanes
Different bike lanes756×702 35.2 KB

Same bike lanes
Same bike lanes754×648 32.1 KB

First of all, by definition, this means that the majority of users who adds it like this trough ID will have meant cycleway= as both sides since whenever this method was introduced. Because the only way to apply that tag, is by specifying both - or adding it manually trough the tagging interface.

2: Editors considered in this proposal and bias it provides

The second thing is, this entire proposal and discussion seems to be about ID and StreetComplete, as if these are the only two, or the two biggest editors out there. Depending on how you look at things, it’s at best one of those, or neither.

I think we can agree that it’s not the only editor out there. As for biggest, that depends on view. Yes, it has a lot of users (source), but in terms of edits, it’s not even top10 (source).

Accepting those statistics are flawed in may ways, but the best I (we?) have to go on, I would like to establish that:

  • In terms of distinct users, ID is by far the biggest, SteetComplete follows as second, but with only slightly over 10% of the number users that ID has. Closely followed by JOSM as third (with slightly below 10%). Maps.me and Organic Maps follow and together have the same market share as StreetComplete (taken together because they’re based on the same codebase, and similar in a lot of ways).

  • In terms of edits however (and therefore, I’d like to think: contributions to the map), JOSM steals the crown by far and StreetComplete isn’t even Top3. ID has about 60% of the users that JOSM has, Rapid another 8%. The next two are revert tools, so not actual editors, and there comes StreetComplete with 2% of the amount of edits that JOSM represents.

You could argue that ID and Rapid should be grouped together in the same way as Maps.me and Organic Maps for similar reason, and then StreetComplete is third, but StreetComplete still is an order of magnitude smaller then JOSM or even ID.

For that matter, I had a quick look into what JOSM thinks is the default, and render me surprised to find out that it has…

JOSM tagging menu, after inputing "cycle"
JOSM tagging menu, after inputing "cycle"322×784 41 KB

… cycleway, cycleway:left and cycleway:right. Implying that it’s either one, the other or if unspecified: both.

Al in all, it’s my humble impression that the proposal and discussion suffers from a multitude of cognitive biasses, where people in favour seem to be either StreetComplete user and/or contributor, in which worlds cycleway:both is the norm and cycleway is therefore perceived as unclear.

To my mind however, as a non-streetcomplete user, saying "you’re not sure if it applies to both sides unless it’s tagged with the :both-postfix, is the same as stating “you’re not sure a road is not one-way until it’s tagged with oneway=no”, where as it’s actually in generally an accepted default.

It’s my impression that outside of that world, people/data consumers seem to have little issue accepting that cycleway without :left or :right does de facto mean the same as cycleway:both - and if it’s tagged where it’s not, it’s a tagging mistake and not a problem with the tag itself.

Which is not to dismiss the issue entirely, someone has to be the first to notice and raise the flag about it. Neither am I saying the majority is always right, but I am actively trying to understand whether this is a data issue, a technical issue, a user issue, or a perception issue (and/or cognitive bias).

I’m happy to let both exist - it really doesn’t bother me - but I’m just not convinced “forcing” cycleway:both as default onto other editors (which is already softened up from proposing deprecating cycleway without postfix all together) is justified - and can’t help but wonder if it shouldn’t be the other way around.

1 Like
34

This approach really would address all of my concerns and points I’ve been trying to raise.

For me, it’s the difference between assuming that it’s usually correct when assuming cycleway covers both sides, vs. that it’s [considered] usually wrong.

That, and at the same time, fixing the real issue - don’t expect ID (or other editors) to adopt this tagging-preference, but do expect it to not ignore it when present (I can wholeheartedly support that).

Thanks, very helpful.

35

Looks fine to me, I looked into some local usage. What stands out is that cycleway=lane in combination with oneway=yes, is both used for roads that only have a cycle lane in one direction and for roads that have lanes in both directions.

For these roads the difference is usually indicated using oneway:bicycle=no/yes.

From my own experience, I have split up a road with cycleway=lane, however forgetting to change cycleway=lane to cycleway:right=lane. If cycleway:both=* was used then this makes it more clear that it needs to be changed.

Leaving room for data consumens to guess if and where there are lanes based on oneway= oneway:bicycle= ect leads to inconsistencies in the interpretation.

1 Like
36

What stands out is that cycleway=lane in combination with oneway=yes, is both used for roads that only have a cycle lane in one direction and for roads that have lanes in both directions.

For these roads the difference is usually indicated using oneway:bicycle=no/yes.

I am not sure the meaning of these tags is clear. How can it be distinguished for a road that is oneway for cars and has cycle infrastructure on both sides, whether these cycleways are going in the same or opposite directions, or e.g. are not oneway (both can be used in both directions). Does oneway:bicycle=no mean that the road as a whole can be used in both directions (e.g. because the two distinct cycleways go in opposite directions, but each is oneway) or that the cycleways individually are not oneway and each can be used in both directions?

37

I might be misunderstanding the question. When cycle infrastructure is mapped onto a main roadway, the flow of bike traffic will be inline with driving on the right. So, a possible situation is to have a single lane for vehicular traffic and added bike lanes on both sides, that are both one way. But the left one is counter flow.

Having cycling paths on both sides of a road that are not oneway does happen. But then these cycling paths have separation and are mapped separately as highway=cycleway.

Here some examples:

(Cycleways mapped seperate)

image
image531×590 81.3 KB

https://www.openstreetmap.org/way/1055102631

oneway=yes+cycleway=lane+oneway:bicycle=no

image
image1099×653 87.3 KB

https://www.openstreetmap.org/way/6842020

oneway=yes+cycleway=lane

image
image876×470 44.6 KB

https://www.openstreetmap.org/way/6501639

38

If I understand you correctly, if a cycleway is a property of a road and not a separate way then by default, each cycleway is assumed to be oneway in the direction of the flow (i.e. right is forward, left is backward in RHT) unless it’s a one-way street in which lanes on both directions are assumed to flow in the same direction as the street.
To denote exceptions, you can use cycleway:<side>:oneway denote that a cycleway is bi-directional or a contraflow lane.

1 Like
39

Thanks everyone for the continued and productive discussion. I reworked the proposal again, yesterday. (This is the third relevant version of the text now.)

The main changes are…

  • Reduce the clutter in the numbers section. I kept the structure and content the same but significantly reduced the clutter. I believe this is all I can do for now, given that the data can easily be considered as presented in a misleading way.

  • Clarify that the proposal does not redefine the cycleway=* tag (Diff). Please have another look at this. I agree that we should try to leave the current definition untouched. At the same time, I think it is helpful for the proposal to be as explicit as possible about what that current definition is. I tried to find wording that aligns with what I understand as the status quo based on this thread. But since there is no (detailed) definition written down that I know of, this is tricky.

In case we don’t find common ground on the current definition, how could I present this proposal in a way that avoids naming the current definition? :thinking:

Other feedback:

  • On Citation: Thanks for explaining your point @roelant. I hope this thread and the proposal will be a good enough basis for a decision for most. I will not have time to add more references, citations, and sources beyond what we already have. I am happy to add suggestions from others, though. — On a separate note, I don’t think there are many – or any – proposals that conform to the quality level you describe.

  • StreetComplete: Thanks for the details on how SC handles the key, @westnordost. I added this to the proposal as additional information.

  • On iD: I agree that iD has to change, and I will continue to work on that change. I find this thread very helpful in informing what this change should look like.

5 Likes
40

But then these cycling paths have separation and are mapped separately as highway=cycleway.

that’s what I would do as well, but from my understanding there is the alternative option to use cycleway=track

1 Like