[Tagging] [tagging] Canoe route / nautical channels

François Lacombe fl.infosreseaux at gmail.com
Mon Jul 2 23:38:56 UTC 2018

Hi all,

Consecutively to edits of page
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

All the best


2018-07-03 0:37 GMT+02:00 Volker Schmidt <voschix at 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 <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
> _______________________________________________
> 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/f595c404/attachment.html>

More information about the Tagging mailing list