Please do not remove transitions. There were carefully added and are accurate.

Please do not remove lane transitions. There were carefuly added and were accurate.

Since 2011, Nearmap usage in OSM is not permitted:

osm.wiki/NearMap_PhotoMaps

Also, please provide the license for the use of Nearmap in OSM. I am not aware that it is permitted by Nearmap. Nearmap do not share their tiles with the community for OSM mapping, unless it has changed?

Hi!

There is indeed a transition from 1 to 2 lanes here. I am reverting back.

This distributor has moved. I removed the POI.

OK thanks!

Hi! Can you explain the changeset comment? Comments should be explanatory and summarize what work was done. Thanks!

Bonjour! Le tag cycleway=separate est utilisé par certains engins de routage pour savoir qu'il faut envoyer les vélos sur la piste cyclable séparée. Si on met juste le tag cycleway:right=separate et pas cycleway:left=no ou cycleway=separate seul, il pourrait proposer le trajet sur la rue au lieu de la piste cyclable. Donc, il est préférable de conserver le tag cycleway=separate dans ce cas.

Bonjour!
L'utilisation de bicycle=no au Québec est plutôt utilisée pour sa signification première: aucun accès, même en débarquant du vélo. Privilégier plutôt bicycle=dismount. Je corrige. Merci!

Hi! Please don't change geometry on highway transitions. These are following the wiki and are standardized for the whole Montreal region (Quebec soon) and aligned on theoritical gore. I will revert. Thanks! placement=transition

Hi! Please be careful and listen to warning and errors in the id editor before saving. This changest breaks geometry. Thanks! I will have to revert. Please recreate a new changeset without errors in geometry.

I am reverting. Please add back the restaurant separately.

Same here, please do not break geometry of roads and other features. Just add the node and listen to warnings and errors. Thanks!

I will revert this changset.

Hi! This changset introduced big error in geometry. Please familiarize your self with osm editing before saving. Also, the id editor did show you errors before saving. You should listen to them. Thanks!

In fact, the main issue is that when someone draws a new roundabout or update one, since the oneway is not there becuase implied, it will not alwys show arrows, and I have seen several roundabouts that were not in the correct direction. Having the tag oneway=yes would have shown the error right away to the user. I understand that implied values are nice to reduce the number of tags, but in that case, it could result in erroneous data because of the lack of feedback. As a rule of thumb, I think that we should never remove implied tags that someone added, because the "duplicate" info here could help confirm the direction and make sure the arrow icons are shown in evey renderer. Just looking at issues in the OSRM project, I can find some issues mentioning that the router did make them use a roundabout in the incorrect direction, for this specific reason. The roundabout was drawn in reverse order and the lack of feedback made it hard to detect. Just imagine a UK user updating a north american or other european roundabout and, by reflex, they could draw it in the reverse direction (clockwise instead of counter-clockwise). Recent version of the id editor are indeed showing the arrows even when the oneway tag is not there, but other editors may not. It may be that all recent editors are correctly showing the arrows and recent routers may all imply the oneway tag for roundabouts, but I would like that until it is proven that all of them do, keeping the old implied tag is way more secure and robust against routing errors.

It's ok, I will add it back myself. Thanks! :-)

Please keep oneway=yes on roundabouts, some older softwares don't automatically apply oneway=yes to roundabouts yet. Adding precision/default tags should not be removed when correct. Thanks!

Merci!