ChaireMobiliteKaligrafy's Comments
| Changeset | When | Comment |
|---|---|---|
| 171690260 | 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. |
|
| 171690260 | It's ok, I will add it back myself. Thanks! :-) |
|
| 171690260 | 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! |
|
| 171730377 | Merci! |
|
| 170716488 | Je ne sais pas... Il faudrait aller vérifier. Je ne prévois pas passer dans ce coin par contre. Vous pouvez mettre un fixme ou une note et poser la question à quelqu'un du coin. :-) |
|
| 171474277 | Thanks! Be careful to reconnect entrances to the home buildings though. I fix these. |
|
| 171379654 | Bonjour! SVP ne pas réaligner les voies au moyen des vues aériennes de l'éditeur. Ces voies avaient été alignées en utilisant des données des bornes géodésiques officielles du gouvernement du Québec. Je vais les corriger. Il ne faut pas aligner les voies sur des photos aériennes sans vérifier l'offset au préalable. Merci et bonne journée! |
|
| 171314252 | bizarre! Alors on garde bicycle=yes |
|
| 171294979 | hi! Please be careful moving nodes we carefully placed. Your aerial imagery seems to be wrong. We are using official geodesic data to align sidewalks and roads. I may have to revert this hard work you did if I find too much misaligned data. Next time, please ask the local community and make smaller changes. Thanks! Please contact your colleagues since they may have the same issue. |
|
| 171301477 | Hi! Please be careful when you remove crossings or links, because the link you removed at the end of Chemin Bates makes pedestrian routing impossible between Chemin Bates and the sidewalk on Avenue McEachran. I will fix. Thanks! |
|
| 171296447 | Hi! Please do not realign nodes as they were aligned using geodesic precise data. The aerial imagery available in most editors is not aligned correctly. Thanks! |
|
| 171295548 | Hi! Please be careful moving nodes we carefully placed. Your aerial imagery seems to be wrong. We are using official geodesic data to align sidewalks and roads. I may have to revert this hard work you did if I find to much misaligned data. Next time, please ask the local community and make smaller changes. Thanks! Please contact your colleages since they may have the same issue. |
|
| 171296383 | hi! Please be careful moving nodes we carefully placed. Your aerial imagery seems to be wrong. We are using official geodesic data to align sidewalks and roads. I may have to revert this hard work you did if I find to much misaligned data. Next time, please ask the local community and make smaller changes. Thanks! Please contact your colleages since they may have the same issue. |
|
| 171314252 | Je me demande si c'est vraiment un mauvais tag... bicycle=dismount sur un traversier, c'est normal non? |
|
| 171147709 | OK, perfect! I guess it is temporary. I will put a construction area. |
|
| 171147709 | Did you survey the area? It was oneway in 2024. Please confirm that this has ben changed since. |
|
| 171101324 | If you see the addresses around this street, their street name is Allée Beaurepaire, so I put that into the official name tag (and name:fr) and put Beaurepaire Drive into name:en |
|
| 171101324 | I am waiting for response from MRNF, MAMH and MTMD (three misnitries with a lot of open data on street names and addresses). We need them to accept that we use their data on OSM even if their CC 4.0 licence is not 100% compatible. See this thread: https://community.openstreetmap.org/t/acceptation-du-mode-dattribution-dopenstreetmap-par-le-gouvernement-du-quebec/127403/15 |
|
| 171089177 | Also, why remove sidewalk presence tags on service roads? It is perfectly valid and makes routing engine for pedestrian route foot traffic on the sidewalk instead of the road. Thanks! In general, you should not remove tags before asking the previous editor or the community. |
|
| 171089177 | When there is a dual carriage we usually count the other direction's sidewalk as present. Otherwise it will be impossible to compare presence of sidewalks on different kind of roads (dual carriage vs single). Please consider the other side sidewalk presence. Thanks! |