[Tagging] Fwd: [tagging] Canoe route / nautical channels
Hi all, >François >I'd add that waterway=canal is really often supported by an artificial >structure and use it to cross a lake as a logical connection between entry >points is awkward. I fully agree that it is not ideal, but in the current situation it is the lesser of all evils. And please note that I am not proposing a new way of tagging, I am just pointing out the current mapping practice in The Netherlands (which is full of navigable waterways with canals changing into lakes or something in between and back again and where the distinction between natural and man_made is theoretical at best) and some other countries I have seen. I came across the undocumented tag waterway=lake by accident. Personally I like that much better than waterway=canal on a lake, but as long as that tag is not widely accepted by data users I thing it really should not be used as a replacement where waterway=canal is currently being used. However, if someone feels so strongly about the negative aspects of the current use of waterway=canal and starts a formal proposal, please let me know, I would be happy to support that. >Why simpler waterway=stream or waterway=river aren't suitable for routing purposes? I fully agree that waterway=river would be much better than waterway=canal in a situation where one more rivers (described in waterway=river as as “linear flow larger natural waterways” ) run into a lake and out again, I think / hope that that is not disputed. My mentioning of using waterway=canal was meant for situations with either isolated lakes (because of the portages I understood the Alaskan example as such) or lakes in a watersystem without linear flow, such as a boezem (separated from and often lower than the open water/sea, to which it is pumped up, the direction (north/south/west being dependent on the pumping station being used). Waterway=stream would be appropriate for a linear flow connection between two lakes if it is so narrow that (according to the wiki) can be jumped across. Waterways so narrow are normally not navigable even for canoes (some specialized/limited whitewater canoes excluded, but you won’t be navigating that acroos a lake). Putting waterway=stream across a lake would suggest that the lake passage is also narrow enough to jump across and not navigable, so there I would suggest waterway=river nstead of stream for the part across the lake. >Volker Schmidt > For the canoe routes, which started the canoe side of this discussion, I > would say that the in-water ways should be tagged as route=canoe without > problems and in concordance with the wiki for the route key "route=x". I pointed out several problems with the use of route=x in my previous post (see below). These problems seem to be a lot bigger than the problem with waterway=canal. Furthermore, using route=x with a value that is similar with an transport mode (as described on https://wiki.openstreetmap.org/wiki/Key:access ) is NOT in concordance with the wiki, for instance see: https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot https://wiki.openstreetmap.org/wiki/Tag:route%3Dbicycle https://wiki.openstreetmap.org/wiki/Tag:route%3Dhorse The wiki states in all these cases that route=foot / bicycle/ horse should be used on relations and NOT on ways. And this is for good reasons as I mentioned earlier, because route=foot an a way would have a really different meaning than the same tag on a relation You will the same for route=canoe, but that is just because I copied the template for route=horse > I could go along with the extension of the definition of waterway=canal to > cover also navigation channels in larger bodies of water, if this solution > is accepted as a result of voting process on a formal proposal. Personally > I prefer a new tag for nautical or navigation channels. I agree that a new tag (waterway=lake seems fine to me) would be better, but until that is formally proposed and widely accepted by data users I see no advantage in banning current practice which is also in concordance with the wiki for instance waterway=fairway (fairway on a lake is added as an addition to waterway=canal/river ) > BTW, the quoted 1800 uses of canal=x are nearly all "canal=fixme", so to > say that "canal=x" is an established way of tagging is misleading. You are right, I saw that after writing my post, apologies. Nevertheless other values are also used and in doesn’t hurt to have a key that specifies a tag wich already (besides this discussion) has multiple uses in the wiki (“transportation, hydro-power generation or irrigation purposes”) >> *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
[Tagging] [tagging] Canoe route / nautical channels
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=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
