Hello Udarian,

Thank you for bringing this to my attention, I appreciate the feedback. I have removed the "sidewalk:both=no" tagging from the motorway links I had added it to (changeset/171042508), as the condition is implied for these ways. However, I have retained the sidewalk tagging on way/1424253772, way/1424253773, way/1424253775, and way/1424253776, as there is sidewalk alongside them visible in imagery and mapped separately in OSM. Thanks again for reaching out!

Happy mapping,
Isaac (VLD280)

Hello spiregrain,

I was hoping I could get some clarification on a couple of edits in this changeset. Specifically, I am looking at way/662478608 and way/1202046938. I noticed you added foot=no to these cycleways, but the aerial and ground imagery I could find seems to contradict this tag value. On the East side of Blackhorse Lane, way/662478608 appears to have pedestrian access alongside the bicycle path, albeit of less than ideal quality in places. On the West side of Blackhorse Lane, way/1202046938 is connected to another cycleway segment with foot=designated and there appears to be signage designating both bicycle and pedestrian access. Since you referenced local knowledge in the changeset, I was wondering if your edits represented some construction or other changes to the area that are not visible in the remote sources I have access to. I have included links below to the ways in question, and to Rapid editor where Bing streetside imagery can be viewed. Thank you in advance for any information you can provide!

Happy mapping,
Isaac (VLD280)

way/662478608
way/1202046938
https://rapideditor.org/rapid#map=20.50/51.58996/-0.04008&background=Mapbox&photo=streetside/1190489170&photo_overlay=streetside

I’m glad I was able to answer your questions. I agree that those tags can seem overspecific, but they offer a good alternative to disturbing established geometry, and I think their usage will increase as bicycle infrastructure becomes more distinct from pedestrian infrastructure. Also, thanks for taking another look at the crosswalk, and especially for taking the time to ground-truth the area. In person surveys are far more valuable than any imagery. I agree that Esri World Imagery (and MapBox imagery as well) can be deceptive. They compile many different image sets depending on locations and zoom, so there can sometimes be significant differences depending on which image set you see. I have found the Esri Wayback website (https://livingatlas.arcgis.com/wayback/#active=27982&mapCenter=-74.00723%2C40.71352%2C11) to be very useful, because you can just click on the imagery to see when it was captured. I often use it to determine the approximate capture time of other imagery sources.

Thanks again for reaching out, and please don’t hesitate to let me know if you have any other thoughts on my edits!

Happy Mapping,
Isaac
VLD280

Good morning MxxCon,

Thank you for reaching out regarding my edits. Regarding way/1384807804, I added this crossing (https://osmlab.github.io/osm-deep-history/#/way/1384807804) based on two separate sources. The zebra paint crosswalk can be seen in the New York State Orthoimagery from 2024 (https://orthos.dhses.ny.gov/?Extent=-8234349.866142837,4950433.133119537,-8233781.067162998,4950669.908757864&Layers=2024_cache,2023_cache,2022_cache,2021_cache) and in the Esri World Imagery from 2024 (https://livingatlas.arcgis.com/wayback/#active=27982&mapCenter=-73.96871%2C40.57964%2C19). I felt confident adding the crossing as both sources were relatively recent, but local knowledge is always superior. If you are aware that the crosswalk has been removed, then I definitely appreciate the correction.

Regarding the "footway:crossing:markings=zebra" tag I used on way/1083318697, I added this tag based on the OSM wiki page for the “crossing:markings” tag (crossing:markings=*). The tag in question, along with the related tag "cycleway:crossing:markings=*", is referenced under the ‘More Difficult Cases’ section heading. Since the two crossing types were already represented by a single feature, it seemed appropriate to make use of this tag rather than alter the existing geometry.

I hope my explanations here were able to answer your questions. If I can explain or clarify anything else, please let me know. Feedback and advice from experienced local editors is always appreciated!

Happy mapping,
Isaac
VLD280

I appreciate the fast and informative response! It is helpful to know that these crossings are legally protected in Quebec and that they are accounted for in the OSM documentation. I’ll make sure to keep your explanation in mind for any future editing I do in Quebec. For the benefit of anyone else who might look into these features, I have included some links to sections of the Quebec Highway Safety Code I found which support your explanation.

https://www.legisquebec.gouv.qc.ca/en/document/cs/C-24.2#se:369
https://www.legisquebec.gouv.qc.ca/en/document/cs/C-24.2#se:370
https://www.legisquebec.gouv.qc.ca/en/document/cs/C-24.2#se:450

Thanks again for the help,
Isaac (VLD280)

Good afternoon ChaireMobiliteKaligrafy,

I have recently begun working on some pedestrian mapping around Montreal with a focus on pedestrian crossings, and I have a question regarding local traffic laws I was hoping you could answer for me. I have come across several crossings you added in December of 2023 (some example links included below) that don’t appear to be designated by real-world markings or infrastructure. I am curious if there is any local law or ordinance that designates pedestrian right-of-way at road intersections regardless of physical infrastructure. If that is the case, do you know of a resource I could reference to better understand the specifics? Otherwise, if these crossings are not legally or physically designated, would it be acceptable to remove them in order to improve the accuracy of the pedestrian feature network? For reference, I have been using Mapillary imagery uploaded by the user VdM (bicycle, July 2024 and car, November 2023) for my work around Montreal. Thank you in advance for any information you can provide, and happy mapping!

Isaac (VLD280)

https://www.mapillary.com/app/user/VdM?lat=45.564485399999995&lng=-73.66355600000003&z=19.9&menu=false&focus=photo&pKey=1244840703424830&x=0.6419251042086539&y=0.6190869478894332&zoom=0
way/1228767169
​​way/1044389897
way/1229183855
way/1229183879

Hello cubbe8!

Thanks for reaching out about the cycleway crossings. If you could share the object IDs of the crossings in question, I would love to take a second look so I can make sure to avoid the same mistake in the future. I used Mapillary footage from March 2023 (https://tinyurl.com/5xh6e8r7) , so it is possible my information was out of date. Also, just to make sure we are on the same page, my understanding is that cycleway crossings (the nodes and ways) should only receive the crossing=traffic_signals tag (crossing=*) when there are dedicated signals explicitly marked for bicycles like the ones in this article https://nacto.org/publication/urban-bikeway-design-guide/bicycle-signals/bicycle-signal-heads/. In cases where bicycle traffic is obeying the same signals as other vehicle traffic, I don’t believe the crossing=traffic_signals is applicable, even if there is footway crossing at the same intersection with dedicated crossing signals. If you have a different understanding of how to use this tag, I would love to hear your thoughts. Again, thanks for reaching out, and happy mapping!

~Isaac (VLD280)

Hello Fuzzy_42,

Thanks for the update. We will keep this in mind for future edits.

Best regards,
VLD280

Hello Alessandro,

Thank you for your feedback regarding my edits on this relation. I appreciate you bringing this to my attention and thank you for addressing the issue. I will take your advice into consideration and will make sure to be more vigilant when making these types of edits moving forward.

Best regards,
Isaac (VLD280)

Hello RoseySMB!

Thank you for adding the missing buildings to the map! I am reaching out in regards to something I noticed in your recent changesets. It looks like you have added some of the hashtags for your organized editing project in the name tag field of the buildings you have created (examples linked below). Project hashtags are used for tracking organized editing and are generally not relevant to the actual features on the map, so they should only be added to your changeset comment. More information about how to use the name tag can be found on the OSM Wiki (name=*). Could you please remove any hashtags from buildings you have uploaded so far?

way/1305638072
way/1301710444
way/1300759521

Best Regards
Isaac (VLD280)

nicyK19,

Thank you for responding to my comment so quickly! I am glad to hear that you are able to resolve those name tags. Your contributions are definitely appreciated!

Happy mapping,
Isaac (VLD280)

Hello nicyK19!

I am reaching out to you regarding some of your recent edits where you added single letters to the name tags of some features in Madagascar. Specifically, I have noticed 7 different ways (closed and unclosed) that have been given the name “s”. Would you mind clarifying for me your data source or reasoning behind these names? I will include links below to a couple of the features for easy reference.Thank you in advance for looking into this, and happy mapping!
way/1315310862
way/1314622688
way/1313027822

Best Regards,
Isaac (VLD280)

Juochnyierbong,

Thank you for responding and resolving the issue with way/1056823619 so quickly! In order to close the relation relation/14100748, I have drawn and added members (changeset/156409206) to replicate the last error-free version of the relation (relation/14100748/history/7). Unfortunately, I cannot be sure of how accurately this version reflects what is actually on the ground, so please feel free to modify it if you have more up to date information. Thank you again for helping me resolve this issue!

Best regards,
Isaac (VLD280)

Hello Juochnyierbong!

I am reaching out in regards to a multipolygon relation representing a scrub natural area (natural=scrub) that appears to have been damaged in this changeset. Relation relation/14100748 (relation/14100748) appears to have had 4 of its members deleted in this changeset, causing a “multipolygon is not closed” error. Additionally, way way/1056823619 was repurposed as an administrative boundary without removing it from relation/14100748. I am hesitant to repair relation/14100748 myself, as I am not familiar with the area, but it would be best to resolve this issue soon so that the scrub area will display properly on the map. If you have local knowledge of the area, I would appreciate it if you could look into closing relation/14100748.

Best regards,
Isaac (VLD280)

Hi there Nickarri,

I am reaching out to you in regards to several changesets in this area that resulted in a lot of overlapping highway errors. I noticed that most of the driveway features have footways in identical positions, which is causing them to be flagged with this error. I wanted to suggest using the "foot=yes" tag instead of duplicating the way. This tag can be put on any already existing highway feature to indicate that it is accessible by foot. More information about the foot tag can be found here:
foot=*

I would recommend removing the duplicate footways and adding this tag to the driveways if you want to indicate they are foot accessible. This method is more in line with OSM editing practices, as it reduces clutter on the map and makes the relevant data (foot accessibility) more easily available for everyone who utilizes it. I made the changes described here on a couple features in the changeset linked below, if you would like to refer to it as an example.
changeset/153221103

Best regards,
Isaac (VLD280)

Hello MxxCon,
Thank you for reaching out and offering your advice. I have updated the tactile_paving tags for the crossing to align better with the wiki guidance and your suggestions.

Hi MxxCon,
The removal of the crossing node here was accidental. Thank you for noticing and re-adding it. I appreciate it!