Don't add your own house as a camping ground. This is private information. Reverting.

This does not exist. Please do not add non existing data.

The url you cite is not from the official OSM wiki. The only info in the wiki is One feature, one OSM element. As a POIs analyst myself, I tend to prefer using nodes inside buildings. It is more precise because near their entrances, and it is also easier to export since you don't need to export the whole building geometry just to analyze shops and other POIs.

In the whole Presqu'ile area (Vaudreuil, RIigaud, Saint-Lazare, Pointe-des-Cascades, Hudson and Les Cèdres, 100% of the shops and industrial places were added as nodes near their specific entrance to make it easier for updates when more than one shop will be in the same building or building:part. Also, The main issue with using shop tags in a building is that it will by default appear on the centroid of the building, which may be far way from the entrance. We prefer to keep the shops as near as possible to their entrance. Also, when people do routing to these places, it will route on the entrance or on the node, which is more precise than on the building centroid, which mnay be several meters away from the entrance. This is not mandatory, but it helps to keep routing as precise as possible.

When possible, please keep points of interest as nodes, event when building parts are drawn. Thanks!

Si possible, conservez-les lieux d'activité et commerces comme des nodes, même quand il y a présence de building:parts. Merci!

Please use bicycle=dismount when there is no sign saying bicycles are not allowed.

Please use bicycle=dismount instead of bicycle=no, because there is no sign to specify that bicycles are not allowed. Many people, especially children, cross the park on their bicycle, or dismounted and this is perfectly fine. Thanks!

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.