Hi all, Consecutively to edits of page https://wiki.openstreetmap.org/w/index.php?title=Tag:waterway%3Dcanal&action=history 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.
Why simpler waterway=stream or waterway=river aren't suitable for routing purposes? All the best François 2018-07-03 0:37 GMT+02:00 Volker Schmidt <vosc...@gmail.com>: > I do not agree with the proposal to use waterway=canal with a new canal=x > tag to indicate a non-existant waterway for canoes. > 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 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. > > 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. > > > > On 3 July 2018 at 00:02, Multi Modaal <multimod...@gmail.com> wrote: > >> 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 >> >> > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging