Hey! This is a request for comment on the proposal Proposal:Make cycleway:both the default to indicate both sides - OpenStreetMap Wiki
This change would go a long way to making tagging easier to manage by editors and data consumers.
I suggest we use this thread for comments (instead of the Wiki Discussion page).
Please, cross post this announcement on the tagging mailing list on my behalf by sending an email to: tagging@openstreetmap.org
This makes me wonder about sidewalk=* where the standard is to use left, right and both but the use of sidewalk=seperate is discouraged in favour of sidewalk:both=separate already (not to mention they may also exist as a painted lane if rarely so you sometimes have to specify the direction in the key anyway if you want to separate it from a regular sidewalk).
By the way, you can drop the value for a tag to create a generic link instead of manually adding an * for the value (prevents redlinking).
Agreed, I think there is a lot to do in the sidewalk namespace. But we should treat the separately in order to be able to move forward with one piece of the puzzle at a time.
By the way, you can drop the value for a tag to create a generic link
Thanks, changed (in the intro). PS: Personally I am happy with small changes like this be done by everyone.
All sugar coating aside, the whole issue exists only because StreetComplete deliberately chose to break with established tagging at the time and has used its army of minions to get its way.
I donât have an issue with cycleway:both but with the precedent switching to it creates (and yes the same game has been played with iD on other occasions, but two wrongs donât make a right).
I disagree. Please check the âRationaleâ part of the proposal. The main issue is, that cycleway and cycleway:both donât have the same meaning historically. Which is why I consider using cycleway:both in a UI that is explicit on what it is tagging, a good practice.
If we want to learn from the past I would say: The issue stems from us using generic tags that are not explicit about their side/direction; which was common in the early days of OSM. But we should make an effort for all new proposals to be explicit about this (which we did in the parking:* proposal for example).
Up to April 2017 there was no doubt that the key without side subkey applied to both sides, after copious editing of the wiki by people heavily involved with SC, yes then it might have been unclear. Which underlines my point.
Before trying to improve things I wonder how big is the problem.
The problem is stated as:
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â (e.g., on the right in many countries or when used on a dual carriageway).
- It could mean âa cycleway on both sides of the way.â
But is this really a problem? Mapping in NL I never have seen that cycleway=lane/shared_lane means that there is only a cycleway on the left or right they are always on both sides.
Okay, my experience is geographical limited but is this is problem anywhere?
The argument is made that they are not the same historically and sometimes in cases like the dual carriageway. And as a consequence project like the id-tagging-schema still use the less explicit cycleway field. See eg cycleway vs. cycleway:both ¡ Issue #1025 ¡ openstreetmap/id-tagging-schema ¡ GitHub.
Let me ask the question the other way around: Is there a real problem to change the recommendation to the more explicit :both variant? The proposal suggest to use a soft migration path, not a full on deprecation. This would start a gradual improvement in clarity whenever a users edits the object and decides to update the tags or modifies them.
No, I have no problem to change the recommendation to to :both
The proposal suggest to use a soft migration path, not a full on deprecation.
I did read the proposal page on this:
Make cycleway:both=* the recommended default to indicate that the value applies to both sides of the way. Deprecate the key cycleway=* without any side subkey for this use case.
And now I still do not know what this means in practice. The last part in particular is free to any interpretation. Would be good to improve:
I still think this is non-problem, for me it is not needed, if other see a need, letâs not overdo it.
Yes, itâs making the tagging more verbose and complicated in order to enforce granular detail, which is not how OSMâs iterative tagging works.
Itâs also non-intuitive in really common cases. Letâs say thereâs a bi-directional cycle track on the right side of the road. Right now (if you havenât iterated towards a separate geometry) you can tag that with cycleway=track, which means âthere is a cycle trackâ. Under the colon-infested scheme you need to replace it with two tags, one to say itâs on the right-hand side of the road, another to clarify whether itâs bi-directional. Even I canât remember what the tag for the latter is (cycleway:oneway=no maybe?) and I do this sort of stuff for a living.
But how do I now know that the cycle track is only on the right and not on both sides of the road? Since no side is specified in your case, I would personally interpret this as both sides of the road. Because according to Wiki, cycleway:right=track would have been used.
And if we now assume that this road with the cycle track on the right-hand side is a one-way street. How do I know if I am allowed to cycle against the one-way system? For me, âcycleway=trackâ would always mean that this is the case on both sides and then I would have a cycle track against the one-way direction and would be allowed to cycle through it as a cyclist. The Wiki says âIf there is only one cycle track add: cycleway:right=track âŚâ. In the Wiki there is also a section for oneway roads, but it is not clear to me what applies if the cycle track is on both sides, as it only talks about left:oneway and right:oneway. I would assume that it would then be cycleway:oneway=no.
In this tagging, I would understand that the cycle track is on both sides, as no side was specified. You understand that it is only present on the right. And I think thatâs the problem, isnât it?
You donât. cycleway=track means âthere is a cycle trackâ and nothing more.
You may as well deprecate adding roads without names, or buildings without heights, or abandoned railways without end dates. OSM tagging is iterative and it doesnât have to be complete at first attempt.
What this proposal is suggesting is to eliminate the lowest tier of tagging and to force people to enter more details, even if they might not know them (the âI remember I cycled along here on a separate track but I donât recall which side of the road it wasâ scenario). That isnât how OSM tagging should work.
Should we then adapt the following sentence?
Until now:
Deprecate the key
cyclewaywithout any side for this usage.
In the future:
Deprecate the key
cyclewayas default without any side for this usage.
While I think you are comparing apples with oranges in your examples, I do agree that it should be possible to iteratively add and refine data for as many tags as possible. So if cycleway=* can be read as âhere be cycleway, please fix meâ, Iâm happy. Iâd rather have this information, than a wrong cycleway:<side>, because someone misunderstood what left and right means in this context.
Iâll be honest and say I really donât know what âdeprecating as defaultâ means!
If an editor author decides that it makes more sense to offer a UI with checkboxes for âcycleway on leftâ and âcycleway on rightâ, and ticking both sets cycleway:both, and no UI is offered that leads to a plain cycleway tag, sure. Thatâs a UI decision for the editor author and Iâm not sure what any wiki deprecation or otherwise has to do with that. But I may genuinely be missing something.
I wholeheartedly agree with these sentiments.
While I appreciate the proposal for itâs intention and the thought that went into it, cycleway without side postfix is widely used.
For one, the statistics that the proposal refers to, actually present a skewed image, because they donât look at the total tag-usage but only at individual values. Taginfo has 1 509 580 for cycleway:both= and 1 073 903 for cycleway=, thatâs nothing to spit at and gives a much better idea of how they compare than the split graph.
Besides that, those numbers might actually be an argument against, in my book. Based on the discussion here, accepting the hypothesis that cycleway:both= is primarily used/added/popular among StreetComplete-users. If thatâs indeed true, itâs a good thing to remember that those by definition donât add the tag by hand (but tap an answer in their quest), as opposed to users of other editors (letâs, for neutrality sake, say JOSM) who do.
And if thatâs indeed the case, itâs actually a compelling argument to let both exist. Not deminished by the fact that cycleway with postfix is more complicated, in other words: more error prone and in general less accessible to new mappers. And, as has been pointed out:
It indeed allow for a granular level of control/detail. Same as adding sidewalk=left/right/both is a very low level, easy and accessible way for people to indicate that a side walk is indeed there, without having to get into the nitty gritty details about it if theyâre not ready to, the same logic applies to cycleway to some extend - especially some of the basic values such as cycleway=no. So again, itâs just a more accessible tagging scheme that allow new mappers to âeaseâ into mapping.
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â (e.g., on the right in many countries or when used on a dual carriageway).
- It could mean âa cycleway on both sides of the way.â
While I did read this in the proposal, that doesnât make it fact. Iâm actually quite curious what the factual basis for this is? Where can information that support these statements be found? Are there renderers or routers that get confused by the lack :side postfix? Because if not, it might be more like a perceived problem then a factual one - but Iâm open to learning that it is actually confusing in a significant way.
To illustrate, personally I thought that adding cycleway=shared or soon probably cycleway=no would add in case of, say, a highway=residential as it shows that Iâve been there, and confirmed that no cycle-infrastructure is present (as per the definition of both). However, it was recently explained to me by someone that this is an assumed default just as much as oneway=no or bicycle=yes for this road-type and therefore has no actual added value. No renderer or router will treat the road different for it.
The same seems to apply for - say, as an example, given your other proposal and RFC - cycleway=no vs cycleway:both=no.
And if thatâs the case, the same logic that actually is the basis for the Proposal:Deprecate cycleway=shared - OpenStreetMap Wiki applies here too (emphasis mine):
(âŚ) suggest replacing it with more accurate tagging or removing it when it provides no additional information.
So, pending the factual basis for the presumed confusion that is the basis for this proposal, I think there is added value in letting the simplified scheme exist side-by-side to the more detailed one, both to encourage new mappers that donât use an editor which selects the tag for them, and as a convenient shorthand for more experienced mappers.
Iâm incredibly sorry that I couldnât make you understand what I wanted to say. English is not my mother tongue, which is why you didnât understand my text I guess 
May I read that you are bothered by the word deprecated?
Well, with just cycleway=track you do not know is it oneway or not either. So to specify it you would need some weird extra tag anyway.
As far as I know, if you have alone cycleway=track or alone cycleway:right=track and no other cycleway info you need to make the same guesses is it oneway or not.
Thanks to Any tags you like - OpenStreetMap Wiki you are free to put cycleway=track even if it would be deprecated.
Would you be still against describing cycleway=track as âbetter replaced by more specific taggingâ?
(personally I have no strong feelings about cycleway vs cycleway:both but I treat cycleway=track and cycleway:*=track as calls to replace it by separately mapped geometries, at least in my region)
No, I just donât know which particular âdefaultâ youâre referring to! 
âDeprecatedâ I understand - in an OSM context it means âthis is no longer recommended by the wiki documentationâ. But âdeprecated by defaultâ I donât quite follow - whose default? The iD tagging UI (in which case presumably it should be an iD pull request rather than a wiki vote)? Some way of rephrasing the text on a particular wiki page?
I kind of disagree with that notion for two reasons: Iâm sometimes adding parking (restrictions) and that is only defined with :side and I also have mapped separate sidewalks multiple times which means I had to switch from one mode of tagging to another.
Itâs actually part of the reason why I support despite the user-friendliness without :side as it feels more complete that way and also allows for more complex tagging (and cycleway has shown the limits thereof).
Granted, it doesnât help that there arenât good presets for sidewalks in both iD and JOSM (yes, you can add them yourself for the latter but still) unlike for parking (the former which has official support, the latter as an external template) but that still can change in the future.