[Tagging] Fwd: [tagging] Canoe route / nautical channels

Multi Modaal multimodaal at gmail.com
Tue Jul 3 11:32:52 UTC 2018

Hi all,

>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
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:




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

More information about the Tagging mailing list