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.

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.