Hi! This is not a standard way of tagging cycleways. The cycleway tag is already on the main road segment. I will revert the edit. THanks for your understanding!

Hi! Please do not add library in the building itself, since it creates a duplicate. The library is already there as a node, and building=civic is quite right here. nodes are generally way easier to parse and analyze then buildings, which can have muitple functions. Thanks!

The error/warning tool we used is a modified version of the idedtor which alert when there are error in tagging or ambigous information, like a cycleway=track with buffer. buffer should be used alongside cycleway=lane

You can see a summary of the proposal here:
osm.wiki/Talk:Proposed_features/cycleway:separation
This discussion is pretty much the one I had with some people some time ago. For my part, it was due to how I mapped the motorway links merging segments as separate way until the end of the dashed lines, which they said it was incorrect since there was no physical separation and thus needed to use the lanes tag instead. This is the same thing here. The general concensus seems to be that we should not map things separately (or in this case cycleway=track wich implies physical separation) when there is only paint separating the ways (or bollards). The REV is a kind of compromise here, because we did not want to map the cycleway separately only at the intersections and make the map really messy, so we used a separate cycleway from the road all the way through.

You can see the discussions about motorway on-ramps here:
changeset/103991053
and on slack:
See #questionable-edits on openstreetmap channel (Monday May 2nd thread: Seems we have some interesting interpretations on highway ramp tagging in Quebec today)

This looks promising: osm.wiki/Proposed_features/cycleway:separation
I would suggest to keep cycleway:right/left=lane and add cycleway:right/left:separation=bollard
together with cycleway:right/left:buffer=BUFFER WIDTH IN METERS
this would be fitting the physical cycleway 100%.

I understand, however, the REV has concrete separation at each intersection, and the cycleway:right/left:buffer is used on Sauriol cycling path to emphasis separation width. I wish there was a cycleway:bollard=yes tag but there is none for now. Problem is a lot of error checking tools will trigger an error/warning on highway=[any vehicle road] with cycleway=track when the cycleway is not mapped separately with highway=cycleway. Not a big problem for me right now, but other users may revert back to lane tag. I had long discussions with fellow osm mappers about what is considered a physicial separation and paint and/or bollards are not right now. In the meantime, I will search for any tag that could describe the bollards in any way.

Please do not map Sauriol cycleway lane as track. There is no physical separation, only bollards in the summer. For a track according to wiki, there should be a physical barrier or curb separation. Thanks!

No response so far... You can remove the coordinates and access=yes in batch. I will fix the duplicates as I see them (needs some surveying)

I contacted the user that imported the data. Still waiting for a response. If I get no response in the next week, I will contact the organisation itself (Fabrique de Mobilité Québec)

I fixed the ones in Sainte-Anne-de-Bellevue (one of the 4 was not at the right place). Please validate data before a massive upload, and check for duplicates, because I added some of these taxi stands already and now, we have duplicates.

J'ai remis le nombre de voies. Y avait-il une raison de retirer cette information?

See osm.wiki/Proposed_features/Add_a_systhematic_location_to_put_the_merging_node_when_merging_exit_ramps_on_motorways_or_other_highways

> Though your method has the same "not always the same angle" problem and has fundamental issue of redefining widely used method.

Our method place the merging node at the end of the dashed merging lines, always. And it was used for the whole motorway network of the Montreal region for almost 2 years now. This is just now that we get objections about this mapping choice. The local community did not object this. But I am 100% for a better international consensus here, so I will try to find a better way to do things so we can both be happy with the results. However, I still think that putting artificial angles (angles which vehicles would not follow) in the roads and crossing continuous lines with highway merging segments is questionnable (and that has no relation with mapping for the renderer, it is more "mapping for realistic vehicles movements"). I understand that we should not have more than one way for road with no physical separation, but the exact location of the merging node should be clarified in the wikis and the end of the dashed line is applicable 95% of the time and is systematic, at the cost of having longer merging segments. I did apply the wiki and also added precise placement=transition with width:lanes tags (this work is not done yet, because time consuming), which was explained to me by accute german editors before I started to map the area. I am a bit suprised to get your comments now but I really wish we both can come to a satisfaction.

The tagging scheme we used is not for rendering purposes, but for a better representation of the movement of vehicles on the roads. And also to reduce artificial angles in the roads, since more precise simulations need to be able to penalize turning radii and angles correctly. I have no problem reducing the merging segment lengths, but there must be a precise way of choosing the right distance.

I moved the merging nodes to the bridge boundaries for now, as you suggest, until we can discuss the issue in detail for the rest of the Montreal motorway network.

Also there is the problem of snow here in Quebec, so if you merge using a sharp angle segment cutting the continuous lines which should not be crossed before the dashed lines the lines may not be visible at all and there could be 3 feet of snow over these lines, so having a merging segment that follow the real path could be safer, isn't it?

See this image instead: https://ibb.co/VYwzs6c

HI! Thanks for your input on this. The problem with the actual wiki is that the merging angle is at the discretion of the user editing the data. My method is systematic and always works, and also follow the real movement of the vehicles using the merging: just start the merging as soon as the continuous lane changes to dashed line and connect it as soon as the dashed line finishes. In this exact case, just in the middle when the dashed lines continues into the next split. See this image: https://ibb.co/bJGdFpX, can you tell me which white line (which angle) would be suitable for the merging here?

Hi!
Please use bicycle=dismount in parks and paths because otherwise, some bicycle routing engines will block bicycle routing if bicycle=no is used, which is not realistic because people can still use these paths when dismounted.

The goal here is to make the representation of lanes to be as realistic as possible. The main problem we have with usual merging angles is that they are in an angle that no vehicle will follow on the ground and makes it difficult for upcoming automated vehicle to have a good understanding of the real merging distances (I'm a transportation engineer and I teach vehicle automation and I know this is becoming a problem). Also, connecting the exit and enter lanes makes it obvious that there is no segment on which the vehicle can travel in transit between the entering and exit segments. We instead use precise placement=transition with width:lanes:start and width:lanes:end tags, so we are following the wiki for these tags correctly. I don't see how it does not fit the actual wiki for the merging lanes anyway, since it is just a matter of angles, which are not specified in the wiki. The distance between the real physical separation and the merging connection is not explained or precised in the wiki, so we just make the angle smaller to enhance the realism of the lanes on the ground. We want to use the real angle that is followed by vehicles when travelling in these merging lanes. We are currently builing a wiki for Quebec to explain the rationales for this and will publish it soon. I am pretty sure it will become useful for a lot of coutries in the next years anyway, since the vehicle automation softwares will need more realistic representation of the lanes and merging segments in the near future, if we want them to use openstreetmap data instead of private closed data. And this is one of the discussions the automation software companies and car manufacturers are having righ now.