Hello! I am looking into deprecating cycleway=shared (not shared_lane). Please find the proposal at Proposal:Deprecate cycleway=shared - OpenStreetMap Wiki
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
Ha, and I thought it is already long deprecated! Well, it’s overdue, thank you!
Thanks! I cross-posted this RFC on the tagging mailing list.
Please note: Since the restructuring of the cycleway wiki page in the course of the cycleway=opposite deprecation a few weeks ago, cycleway=shared is already listed under “Deprecated or discouraged tags” there. Some argue that it is de facto already deprecated, but I think an explicit discussion and vote on it can’t hurt.
I hope this is just as low hanging fruit as the cycleway=opposite-deprecation!
Please, cross post this announcement on the tagging mailing list on my behalf
done (sorry for the dupe, was interrupted while doing it and then didn’t see it had already been done)
Long overdue indeed!
I’m glad to see that the final proposal doesn’t require explicit tagging for bicycle=yes in conjunction with cycleway:both=no, a double tagging requirement which would’ve made it less accessible for new editors, more error prone and in generally overly complex. I admit that I was concerned when I read that in the first draft. 
The current proposal aligns nicely with the sidewalk= mechanism (allowing for sidewalk=left/right/both and sidewalk[:left/right/both]=). However, that should also imply that cycleway=no is also allowed (instead of and/or as a shorthand of the longer cycleway:both=no) and should probably be documented and added to the example?
It was done prematurely, and addressed as such here, just not corrected yet.
It seems to me like the person who did the restructure understood the tag to be deprecated entirely, while the previous version of the page clearly indicated* that it was only deprecated in conjunction with highway=cycleway and not in conjunction with other highway='s, such as the in the proposal mentioned highway=residential. In other words - they were a bit over enthusiastic, it seems, in the clean-up of what’s deprecated and not.
From this version:
cycleway=shared
In general, this indicates that cyclists share the road space with other traffic.
Note: This has also formerly been used on cycleways which were mapped as separate ways tagged as highway=cycleway before the segregated=* tag was formalized. Its use with highway=cycleway is now considered obsolete.
Emphasis mine.
Edit: Oh, I see now it was actually you who did that clean-up. 
Hi 
- maybe you could actually elaborate on it yourself then (either here or in the other topic) instead of me making assumptions. 
I don’t think this will make the proposal more clear. The number I collected for [RFC] Feature Proposal - Make cycleway:both the default to indicate both sides - #7 by emvee show, that in the case of no the usage is clearly in favor of bicycle:both=no and given the uncertainty on it’s side when using cycleway=* I would prefer to keep it as is. Those mappers that know about this debate will also know to leave it if they must…
The number I collected for [RFC] Feature Proposal - Make cycleway:both the default to indicate both sides - #7 by emvee show, that in the case of
nothe usage is clearly in favor ofbicycle:both=noand given the uncertainty on it’s side when usingcycleway=*I would prefer to keep it as is.
cycleway:both=no is not the same as cycleway=no because it is more specific. You could have cycleway=no cycleway:left=track (which would override the no), but cycleway:both=no with cycleway:left=track would be an error. (assuming that the rules established for access apply)
I don’t specifically see the numbers you’re mentioning there, but given the fact that your other topic is also still a proposal and not without resistance, it seems inappropriate to me to document this proposal as if that proposal is already been accepted.
I’ve an opinion on that too, which I’ll add there, to prevent having the same discussion in two places.
@roelant @dieterdreist I have updated the example row 2 Proposal:Deprecate cycleway=shared - OpenStreetMap Wiki to clarify that adding bicycle infrastructure tags might require separate tags per side.
Does this address your feedback?
Thank you for tagging me.
My objection is that your proposal anticipates acceptance of your other proposal and words it as such.
Your change does not address this.
If anything, adds insult to injury, because the proposed documentation adds to the perceived confusion between cycleway= and cycleway:both= instead of trying to prevent it (by suggesting the :both-postfix is required to indicate that it is actually about both sides).
I don’t see any difference between cycleway=no and cycleway:both=no
The first one means, there is no cycleway, the second one says threre are no cycleways on both sides. This is like 0 = 2*0 - it is the same.
cycleway=no + cycleway:left=track is the same mess as cycleway:both=no + cycleway:left=track
cycleway=no being overridden by a different cycleway:left or :right is also an extremely rare combination in the database, compared with all cycleways mapped, it only occurs 154 times. This suggests that almost no one actually maps that way and it’s a purely theoretical argument.
I also see no real reason to use this hierarchal overwrite concept here with only two options (left/right). It only saves a minimal amount of description length but creates ambiguity.
Update: I now see that I only updated the examples to talk about separate left/right cases but not the migration path section. I added another row there as well so all places now recommend to either just remove, add an explicit “no” or add bicycle infrastructure tags per side.
The proposal looks good to me.
I took proactive action and removed the last two occurences of cycleway=shared in Hamburg. One of those started out as cycleway=street 15 years ago.