[Tagging] [tagging] Canoe route / nautical channels

Volker Schmidt voschix at gmail.com
Mon Jul 2 22:37:39 UTC 2018


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 <multimodaal at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180703/1fb787bc/attachment-0001.html>


More information about the Tagging mailing list