Can you be more specific please?

These are old data, I will update with width:lanes tags. Thanks!

The main problem with merging as soon as the physical separation ends is that more and more routing engines calculates penalties for trucks and buses according to the angle of the road, so these creates artificial angles that add non-existing penalties. Thanks!

We decided to split the motorway links at the beginning or end of the dashed line merging area in the Quebec province for better representation for autonomous vehicles and routing, which will be needed soon. We use the placement=transition with width:lanes instead, so it is more realistic. We will create a wiki page soon to explain the rationale for this.

Can you be more specific? Which new tags? Thanks!

Yes, we are currently revising our validation tools to be more flexible. In the meantime, I will clip on residential borders and it should be fine. Thanks!

I thought a lot about this so I am not surprised by your comment, because I had the same with myself! However, the problem is our validation tools are checking for residential areas with the flats=[integer] tags and then check in the landrole data to make sure the number of flats is correct for this area, while also checking for residential buildings with building:flats count. This allows us to validate all residential data with multiple databases and indeed have the correct number of flats everywhere, even in rural and low-density areas. If we remove the residential areas with their flats tags, this validation will not be possible. I would prefer that we make sure that natural=wood takes precedence over the residential area so that it does not have a grey background. However, I went looking at the carto rendering github issues, and found that the rendering of wood icon over grey area seems to be an intentional feature, even if multiple persons said it was weird: https://github.com/gravitystorm/openstreetmap-carto/issues/1796

Oui je comprends, par contre, nous sommes en processus pour rendre les données beaucoup plus précises avec nos partenaires. On a commencé à découper les landuse sur les côtés d'îlots en bordure de rues, pour pouvoir éventuellement calculer automatiquement les largeurs de rues et mesurer les superficies des zones de manière précise. On veut aussi se rapprocher de la manière dont les découpages sont faits dans les rôles fonciers et dans les municipalités. On a déjà complété ce travail sur la rive sud entre Brossard et Châtegauguay et dans la Presqu'île (Vaudreuil, Saint-Lazare jusqu'à Rigaud) ainsi qu'à Sainte-Julie et Drummondville et le plan est de compléter toute la région de Montréal ainsi que le Québec dici 3 à 5 ans.

Bonjour! J'ai déconnecté votre polygon de terminus des rues autour, car cela cause des problèmes lorsqu'on veut les éditer plus tard. Merci! Il est préférable de dessiner les areas séparées des rues et paths, pour faciliter leur édition.

C'est déjà corrigé :-) Bizarre pour le passage hors-piste, car le trottoir est codé avec bicycle=no comme tous les autres de la région. Peut-être que le logiciel utilise de vieilles données...

Dans votre dernière mise à jour, la piste cyclable apparaissait 3 fois de manière superposée et était connectée à une zone résidentielle plutôt qu'au reste du réseau routier.

Cette voie cyclable n'est pas séparée physiquement de la rue (avec du béton, une clôture ou du gazon), alors on la code comme attribut de la rue (cycleway=lane) et on l'avait déjà bien complétée. Merci!

But, yes, there is no real exit names in Quebec, only exit numbers. Only the destinations and nearby towns appear on the signs.

I don't know what is the correct naming for exits in Canada. You can ask the community. I am mostly responsible for standardizing road alignements and road tags in Quebec. Thanks!

I will need to revert this changeset. This is the way we map the motorways here, with precise lane merging according to exact lane centerlines, for autonomous vehicles and modelling and analysis requirements. You can propose a new changeset for the exit names though if you want. Thanks for your understanding!

Thanks! In fact, we usually use entrances according to their main functions:
entrance=shop : main entrance for customers and/or employees for a commercial or industrial building
entrance=main : main entrance for visitors and/or employees for a public building, a park pavillion or a social facility (like a retirement home with employees)
entrance=home : main entrance for residents of a residential building
We never used entrance=service before, but we may change its function as you suggest. Thanks!

Hi! This entrance is for both the employees of the residence (main entrance), and the residents themselves (home entrance). In our tools, we need both tags to be able to route residents to their home, and employees to the main entrance. Removing one of the tags makes it impossible to know that this entrance has a dual function. Can you explain why using both tags is problematic?

OK, sorry, I did not see that there was already a node with the same info. :-)

Can you explain a bit more what was wrong by setting the building as a subway station. This is a legit subway station...

Fixed, sorry!