Changeset When Comment
188667542

Likewise thank you for all the mapping and quality assurance you do. With a schema less system like OSM it is invaluable to have someone catching the outliers and making the data usable for data consumers.

123443212

Hello. Happily this is a gravel quarry not a grave quarry. And for that matter I hope the practice of mining graves (e.g. for Mummy Brown https://en.wikipedia.org/wiki/Mummy_brown) is solidly in our collective past.

fixed via: changeset/189491500

188667542

Hello again! Purely a typo on my side. Thanks for catching it.

fixed via changeset/189491266

Cheers,
scarapella

187446125

Hi alexanderwoods,

Thank from letting me know and for fixing it already.

Cheers
scarapella

187797857

Hello,

Thanks for setting me straight about the usage of locks especially in the Netherlands. I am always happy to learn something new and I'll of course take care of cleaning up my edits.

As for why I didn't tag anything motorboat=yes, the answer is simple. I was looking for places where I clear evidence of use by paddle craft. I wasn't trying to tag for anything beyond that.

As I mentioned I was not away of the CEMT tagging scheme until you brought it to my attention. With that knowledge I do agree it would be more explicit to have both motorbot=yes and canoe=yes in those cases.

Cheers,
scarapella

187797857

Hello JeroenHoek,

Thank you for brining my attention to the CEMT= classifications. It was not one I was familiar with despite doing a fair amount of waterway mapping in Europe. Looking at the CEMT= documentation, I can only agree that it implies canoe=yes and therefore having both CEMT=0 and canoe=yes are technically redundant. While I tend to follow with the sentiment that redundant tags are usually unnecessary, I think they are helpful in some cases. This is especially true when one tag is more commonly used globally and the other is a less common, regional tag. As canoe=yes is a more common tag than the CEMT scheme and globally used, it helps data consumers acting globally to understand that paddlecraft may use these waterways. While I do not condone tagging for the render, I do condone including the most commonly agreed upon tags. At worst, tags with redundant meaning do not meaningfully hurt anything. (cf. the < 1 200 000 instances of highway=path|footway + foot=yes). I also noticed I am not alone in this tagging as other mappers have tagged > 110 waterways with CEMT=0 and canoe=yes, mostly in the Netherlands. https://overpass-turbo.eu/s/2vho

My tagging of canoe=no on lock=yes is based a small part on global common practice (most locks globally exclude paddle craft), but mostly inferred from evidence of usage. i.e. if I see a strong heatmap signal of paddle usage and all of it bypasses the lock itself using a portage (especially one that does not follow the visible lock tending path), this typically indicates a lock where paddlecraft are prohibited. In that case I would map the lock as canoe=no and provide a connected portage path around the lock to allow routing engines to find a contiguous paddle journey. As this is a heuristic model, it is good, but not foolproof. If the convention in the Netherlands is the inverse of globally and canoes are typically allowed in locks by default, then I will happily have learned something new and update my previous mapping.

Cheers,
scarapella

187487797

Hello,

I'll take another look at the possibility of routing with synthesized lines as you mention. Hopefully I'm over estimating the complexity.

As for your particular route, it will actually be route-able in the next few days on PaddleMap as I happened to update the portages over the weekend. 🙂

Another issue you might face even when there is a waterway mapped is canoeing obstructions. Take for example this route on the Songdalselva which seems like it should be fine https://paddlemap.net/#map=12/58.2168/7.7248/standard,waterways,opentrailmap-canoe-pois,opentrailmap-canoe&lonlats=7.698669,58.242843;7.850761,58.141278

This is caused by the waterfall node/11215088987 You can override this by tweaking the parameters in the paddle routing profile or switch to the waterway profile. However, it would be nice to have a feature to easily debug that.

Cheers,
scarapella

187487797

Hello,

I'm with you on canoe=no feeling quite absolute. I often find myself tagging canoe=discouraged for very similar reasons. Although if I think about the most I can get from a map is what difficulty the rapids are since rapids=3 vs. rapids=4 is quite different. So I try to tag that when I can. Otherwise, people will make a decision when they see it.

I would love it if paddlemap supported routing without flowlines. In general I like the idea of flowlines and think they should be mapped. I mean every governmental waterway database I'm aware of (Canada, Europe, US) all include flowlines. However, in practice tons of them are missing in osm, so routing without them would be great. The real solution (to dynamically infer them) is non-trivial from a coding perspective. So maybe someday. The only trivial solution I've thought of is to route along the way that describes the natural=water area (a bit like happens with pedestrian areas). But that is unsatisfying and relies on people intersecting the waterway=* with the natural=water.

for #2 do you have a specific route link I can troubleshoot just give me a link.

Cheers,
scarapella

P.S. I'm findable on OSMUS slack (often) and OSM discord (in theory, but less in practice) if you use either of those.

187487797

Hi balchen,

Purely FYI, canoe=portage on a waterway=* is absolutely a documented way to indicate "don't canoe on this waterway". However, it's not commonly and not well supported by data consumers. canoe=no on waterway=* is a more commonly used tag.

Cheers,
scarapella

139974915

I have to admit the root cause is probably PEBKAC...

139974915

Yes, you are correct. The (anti-) pattern in iD I must have executed was

* update resource=gravel using the resources box (and not the tag box)
* press [tab] in a vain attempt to move selection off of element, but instead move to next resource in list
* press [2] as new line shortcut, but instead enter a resource type of "2"

I'll be sure to add it to my personal qa query on overpass.

Thanks as always for your help,
scarapella

139974915

Thanks for drawing my attention to this. Your intuition was right ";2" was a typo on my part. Fixed via changeset/187081409 and comment closed.

Thanks again for your diligence and precision,
scarapella

P.S. It is a slightly surprising typo as it wasn't simply appending "2" to the end of the value. Which is caused when i try to create a new line before move focus properly off the edit box. But a typo it was nonetheless.

184826471

No worries. There are a lot of tags out there and sometimes multiple different tags you can can use for the same thing. 🤷

I updated as proposed and added a few canoe features while I was at it.
changeset/186878292#map=13/41.94337/-72.06286

Happy Mapping,
scarapella

172060588

No worries. All cleaned up changeset/186877711

Happy Mapping,
scarapella

184826471

Hi NE_SwampYankee,

Thanks for your contributions to OpenStreetMap. I came across this changeset because I was looking for waterways tagged waterway=yes, which is relatively uncommon and hard to interpret from a data consumer's perspective.

For the way way/1222772364 can I propose waterway=flowline instead of waterway=yes ?

Cheers,
scarapella

172060588

Hi aseigo,

Thanks for your contributions to OpenStreetMap. I was looking for cases of node where waterway=flowline when I came across this wetland
way/1430538583

All of the nodes in this area have the tag waterway=flowline. I suspect this was a typo, but before I cleaned it up I wanted to check to see if you had something in mind I missed.

Cheers,
scarapella

186501603

Hi Andreas,

I see nothing wrong with having emergency portages around canoe-able locks. Just as there is nothing wrong with wearing both belt and suspenders. Both are just choices of fashion. 😉

Cheers,
Sean

186501603

Hi Andreas,

Thank you for pointing this out. My (incorrect) inference for canoe=no was based on
* the presence of portage from previous mappers
* a lack of clear strava heatmap signature through the logs
* the fact that on average worldwide, most locks do not allow canoes (although this is clearly not a hard and fast rule).

I've reversed that access based on your timely comments changeset/186505567

Cheers,
Sean

166270216

Hi zystef,

Thanks for your contributions to openstreetmap. It is great to find other people mapping canoe features.

Purely FYI, I updated one of the portages you created on the Flambeau River changeset/186500074 with a canoe=no restriction on the waterway=river as it crosses the dam. That let's routing engines (e.g. on https://paddlemap.net/) know to send canoeist to the portage and not over the dam.

Cheers,
scarapella

183206364

My apologies. I didn't notice the dam was already mapped. It didn't occur to me that a highway=* would also be tagged as a waterway=dam.

Wouldn't it be better to split the two into different elements for clarity.

For example:
* the name=* element is now Barrage Sartigan, but I supposed the name of the road is actually Rue du Barrage-Sartigan across the dam as well on both banks
* the way is tagged as bridge=yes and a waterway=dam.

Cheers,
scarapella