Dear all, New on this mailing list (but not on OSM), so please forgive me if I didn't quite understand the old-school interface of this mailing list (-;
It looks like both these threads are strongly interconnected, so I try to address them both, as they also refer to the work that I am doing myself mapping water areas as wel as waterway networks (for routing and recently starting to develop a canoeing map) https://lists.openstreetmap.org/pipermail/tagging/2018-June/037679.html https://lists.openstreetmap.org/pipermail/tagging/2018-June/037677.html Summary: I would suggest using [waterway=canal] or [waterway=river] for routable lines across bodies of water despite the fact that you normally wouldn’t call them as such. This because of common current practice for routable networks and other practical reasons. This is also in line with the description of common practice in https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dfairway "Use waterway=fairway for the artificially created navigable route marked by buoys in large waterbodies like a lake or a sea. Do not use it as a replacement for waterway=river or waterway=canal. " But to be able to distinguish normal canals from these routing lines, a Wiki for the key [Canal] is just made, where appropriate values can be added without messing up routing (such as canal=virtual?). ----------- *Rendering* Despite being a canoeist myself, I think that it's good that canoe routes / canal lines are not rendered on general maps such as the OSM standard Carto, for such things a more specific map would be appropriate and rendering of areas’s is to be preferred above linear elements. I think the question whether a specific solution renders on standard Carto or not should lead to choosing an otherwise worse solution over one that otherwise is better @Dave Swarthout Would this work for your rendering needs for your canoe in Alaska, for the time being? https://www.openkaart.net/canoe/#map=12/60.6716/-150.5977&overlays=rte (early development version of my canoeing map –and now just a translation of my Dutch version geared towards the specific situation here with water only flowing _up_ - please have a few seconds patience, it collects the data from Overpass) When I find the time I will adapt it for more general use outside the Netherlands (possibly with cached data) and work on the colours etc. I would suggest tagging the footways in the canoeing route with canoe=portage, so they can be easily found (and perhaps also “portage” as “role” in the relation for the highway=* parts involved) This summer I plan to map a lot of signposted canoe routes and when I have a significant number also kindly ask Waymarked trails if they would be interested in rendering them on their great website. *Linear elements in the lake / lagoon etc* For the linear elements across the lake route=ferry would be very misleading; as I hiker I would expect a boat there to bring me to the other shore (like the nice 3 rowing boat-system in the Scandinavian artic). Route=canoe seems better when you just look at the wiki definition, but in actual use it doesn’t work out that well. First it is actually mainly used as an addition to highway/waterway tags instead of as an alternative. Besides that, using route=* instead of a waterway-tag would have making routers look at different keys for the needed routing information , instead of the different values within the waterway-key. Furthermore using route=* for these cases near waterway=* makes life for tagging and data consumers unnecessarily difficult with multiple values in the same key, for instance when you want to tag that a route=* is for canoe and motorboat, but not for sailboat (which is easy on a waterway with a separate access-key for each category). And besides it is confusing between routes on relations (only to be used when the route is physically signposted/marked) and on ways (to be used when the way itself is not visible). *which waterway-value?* Although it might not be perfect when you look of the normal definition, the common practice is that such routable linear elements across bodies of water are either [waterway=river] or[waterway= canal], depending on the situation (there are a lot of them in The Netherlands and also elsewhere where routable networks are made). This common use is also illustrated in the Wiki for signposted routes [ waterway=fairway] is an _addition_ to waterway=canal in a lake or a sea and not a replacement: “Use waterway=fairway for the artificially created navigable route marked by buoys in large waterbodies like a lake or a sea. Do not use it as a replacement for waterway=river or waterway=canal.” And furthermore in a lot of situations the difference between natural and man_made is really not that clear-cut (nowadays even the top few meters of the seawater could be argued to be man-made by out CO2-emissions :-) When setting something form the ground up we would probably use a third tag that indicates such navigable, but more abstract waterways, but changing that now would mess up a lot of routing applications and/or a massive retagging and need for changes in applications. But since the current use of the waterway=canal-tag doesn’t really hurt anyone, that seems more like creating a problem than solving one to me. But on the other hand I can imagine the wish to be able to distinguish between actual canals as you normally would imagine them (within a natural=water / water=canal) and these [waterway=canal] linear elements across bodies of water that are themselves not canals. For that purpose I just created a wiki page for the key canal=* (a tag in addition to waterway=canal). If a value is added for the type of canal (virtual? ; navigation?) those who wish to do so can distinguish the different types without messing up current routing applications by using another key instead of [waterway] or a value for [waterway] that is not recognised as being routable for boats / canoes. The key was already been used more than 1.800 times before the wiki was made, so there seems to be a market for it. Hope this can work for all of us. Cheers.
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
