[Tagging] [tagging] Canoe route / nautical channels

Multi Modaal multimodaal at gmail.com
Mon Jul 2 22:02:33 UTC 2018

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)


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
"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?).



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?


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

More information about the Tagging mailing list