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
