[PATCH] Fix cycleway rendering in combination with oneway:bicycle=no and for cycleway:both

[Emvee]

I was updating a street with oneway access but tow-way access for cyclists, bicycle=no. I expected to see the lanes on both sides of the street but it was only on one side. In a work-around I tried cycleway:both=lane but that did not work, what did work is cycleway:right=lane + cycleway:left=lane but that triggers a validator warning.

From an example to play with, ​http://localhost:8111/load_object?objects=w446091066, enable Mapillary to see pictures of the street. Try replacing cycleway:left=lane + cycleway:right=lane by cycleway=lane or cycleway:both=lane

Two updates in this patch:

1. Handle cycleway:both (​taginfo 133333 times used of which 7158 positive)
2. Render oneway:bicycle=no and cycleway=lane/shared_lane/track on both sides, before it was only rendered on one side

[Emvee]

cycleway_lanes_tracks patch

[skyper]

As the situation about the meaning of cycleway=* together with oneway=yes is not clear and it is often interpreted as cycleway only on the side of the traffic-flow direction, I would prefer to have validator not warn about same values of cycleway:left/right=* together with oneway=yes.

As for the rendering, tags rendered in default mappaint should be in defaultpresets, too, e.g. we need to update it but I see that cycleway:left/right=opposite* needs to be removed, anyway, see #19828.

[Emvee]

I think it is okay for the Validator to warn for the same values of cycleway:left and cycleway:right, this patch enables two alternatives with respect to rendering, cycleway:both=* and just cycleway=*, but anyhow, that is another issue.

For the rendering, cycleway:left/right=opposite* is already not taken into account.

[anonymous]

Ticket #21746 has been marked as a duplicate of this ticket.

[Emvee]

I did forget that I did already submit this patch, so I did create a new ticket and just closed it again as duplicate.

Meanwhile cycleway:both=lane/shared_lane/track is used 14610+6241+5342 = 25193 times, I think a good reason to merge this.

[skyper]

Ticket #22360 has been marked as a duplicate of this ticket.

[skyper]

Ticket #22450 has been marked as a duplicate of this ticket.

[skyper]

Ticket #19910 has been marked as a duplicate of this ticket.

[skyper]

#19910 has some more comments. See also #10317.

[mcliquid]

Regardless of how useful tagging seems to some here (purely subjective). It is a fact that we have a massive increase in usage here, which is simply not represented in the editor. Is this function being actively blocked here for personal reasons?

[taylor.smock]

Not in particular.

I tend to prioritize newly modified tickets when I'm looking for patches to apply. Those patches will tend to have better response times from external contributors and will be less likely to have been looked at and reviewed/discarded by other core maintainers.

Furthermore, attachment:cycleway_lanes_tracks.patch​ will probably not apply cleanly, so someone is going to have to figure out where the changes should actually go.

I'm doing a release today, which means I will not be merging any new code until Thursday at the earliest (significant bug fixes excluded).

[Emvee]

Thanks for linking #19910 and #10317 here, it shows to my opinion there is quite some traction to improve this.

I did just an "svn up" and did not get conflicts so the patch still applies cleanly.

[mcliquid]

@Emvee Is this now ready for merge?

[Emvee]

Yes, I tried to indicate that using my last comment, but yes, the patch merges cleanly with the latest sources.

[taylor.smock]

In 18588/josm:

Fix #19826: Fix cycleway rendering in combination with oneway:bicycle=no and for cycleway:both (patch by Emvee)

[mcliquid]

Thank you! Really appreciate!

[skyper]

Ticket #22566 has been marked as a duplicate of this ticket.

[taylor.smock]

Milestone renamed