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

[Christoph Hormann]

On Tuesday 03 July 2018, osm.tagg...@thorsten.engler.id.au wrote:
>
> A waterway=canal, waterway=river, or waterway=stream way inside a
> lake or pond is probably appropriate to connect an in-flow to an
> out-flow in a direct line, to allow software to easily trace
> waterways through lakes or ponds (which are essentially just widening
> of the waterway) without having to process areas. In this case the
> waterway going through the larger body of water should share a node
> with the outline of the lake at the in-flow and out-flow points where
> they way and the outline intersect.

Connecting waterways through lakes based on flow has been a subject of 
dispute for a long time.  It is highly unlikely that there will ever be 
full agreement on this and even less that this will manifest in 
mapping.  It often boils down to questions like 'Does the Rhone flow 
through Lac Laman or does it enter into Lac Laman and exit again on the 
other side'.

But all of this is something completely separate from the question how 
to map verifiable navigation routes within lakes.

Note a very practical reason not to use the waterway key for mapping 
navigation routes within lakes is that mapping a navigation route that 
coincidences with a river/canal running through and being mapped 
through a lake is much simpler because you can just use an additional 
tag instead of a separate geometry.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny]

3. Lipiec 2018 12:24 od osm.tagg...@thorsten.engler.id.au 
:

> A waterway=canal, waterway=river, or waterway=stream way inside a lake or 
> pond is probably appropriate to connect an in-flow to an out-flow in a direct 
> line, to allow software to easily trace waterways through lakes or ponds 
> (which are essentially just widening of the waterway) without having to 
> process areas.




I am not sure whatever "to allow software to easily trace" is appropriate 
reason,

but at least in some cases rivers/streams are considered to not be interrupted 
by


lake/pond (so stream is not considered to end before lake and start again, but 
is 


considered to exist within lake).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[osm.tagging]

> -Original Message-
> From: Christoph Hormann 
> Sent: Tuesday, 3 July 2018 18:26
> To: Tag discussion, strategy and related tools
> 
> Subject: Re: [Tagging] [tagging] Canoe route / nautical channels
> 
> On Tuesday 03 July 2018, Multi Modaal wrote:
> > [...]
> >
> > 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.
> 
> Note Multi Modaal is trying to push this idea of tagging for the
> router into the wiki as established use of waterway=canal (which is
> obviously not).  Here what i added there explaining why this is a
> very bad idea:
> 
> Such use of waterway=canal is in fundamental conflict with the main
> purpose and primary use of the tag to map artificial physical
> waterways and is therefore strongly discouraged. It can primarily be
> considered Tagging for the renderer to place labels and tagging for
> the router.

Fully agree. 

waterway=canal or waterway=river are not appropriate for mapping either 
physically unmarked routes or routes marked with buoys inside larger bodies of 
water.

https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dfairway does seem 
appropriate for the later. So that's basically the answer to the "nautical 
channels" thread.

A waterway=canal, waterway=river, or waterway=stream way inside a lake or pond 
is probably appropriate to connect an in-flow to an out-flow in a direct line, 
to allow software to easily trace waterways through lakes or ponds (which are 
essentially just widening of the waterway) without having to process areas. In 
this case the waterway going through the larger body of water should share a 
node with the outline of the lake at the in-flow and out-flow points where they 
way and the outline intersect.

> The commonly used method for mapping boat routes with regular service
> is route=ferry. Routes used casually, non-regularly and with wide
> variation in geometry by private boats are not verifiable and should
> therefore not be mapped in OSM.

Where you have a lake, and there are a pair of pretty clear points where it's 
possible to put your canoe (or similar sized boat) in or take it out of the 
water, I do think it's appropriate to connect these points with a route=canoe 
way if it is part of a route=canoe relation (which includes both water sections 
and sections on land).
So that's basically the answer to the "canoe route" thread.

> I hope there will be community consensus not to abuse waterway=canal
> or other waterway tags this way and we can remove the whole paragraph
> again.
> 
> On a general note and as a suggestion to mappers who might be
> irritated about how to deal with OSMs free form tagging system:
> 
> * inventing new tags so far not used and documented is fine - but you
> should document them.
> * adding new uses to secondary tags (like using surface=* or usage=*
> on features it is so far not commonly used on) is also fine if it
> matches previous use in meaning.
> * adding new uses to existing primary tags is highly sensitive and
> should usually be discussed first.  Creating a new tag is almost
> always a better idea.

I agree with all of that.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[François Lacombe]

Hi Christoph,

2018-07-03 10:25 GMT+02:00 Christoph Hormann :

> * inventing new tags so far not used and documented is fine - but you
> should document them.
> * adding new uses to secondary tags (like using surface=* or usage=* on
> features it is so far not commonly used on) is also fine if it matches
> previous use in meaning.
> * adding new uses to existing primary tags is highly sensitive and
> should usually be discussed first.  Creating a new tag is almost always
> a better idea.
>

I merely agree with all those points except there is no primary tags but
only tags.
What is primary for a given mapper will be secondary for someone else,
despite so called primary tags are more used than any others.
A tag may be primary for a specific render but secondary for routing. Then,
saying a tag is primary is tagging for render or routing or any particular
purpose.

Given example is waterways in tunnel
If I look for waterways, then waterway=* will be the main tag I'll look for
If I look for tunnels, then I'll look for tunnel=* and don't even look at
waterway=*

Then it should be really simpler to extend values on existing tags when
it's relevant (which is the only criteria)
Defining primary and secondary tags just put pointless barriers on
refinement process and I don't see any benefit.

All the best

François
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Christoph Hormann]

On Tuesday 03 July 2018, Multi Modaal wrote:
> [...]
>
> 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.

Note Multi Modaal is trying to push this idea of tagging for the router 
into the wiki as established use of waterway=canal (which is obviously 
not).  Here what i added there explaining why this is a very bad idea:

Such use of waterway=canal is in fundamental conflict with the main 
purpose and primary use of the tag to map artificial physical waterways 
and is therefore strongly discouraged. It can primarily be considered 
Tagging for the renderer to place labels and tagging for the router. 
The commonly used method for mapping boat routes with regular service 
is route=ferry. Routes used casually, non-regularly and with wide 
variation in geometry by private boats are not verifiable and should 
therefore not be mapped in OSM. 

I hope there will be community consensus not to abuse waterway=canal or 
other waterway tags this way and we can remove the whole paragraph 
again.

On a general note and as a suggestion to mappers who might be irritated 
about how to deal with OSMs free form tagging system:

* inventing new tags so far not used and documented is fine - but you 
should document them.
* adding new uses to secondary tags (like using surface=* or usage=* on 
features it is so far not commonly used on) is also fine if it matches 
previous use in meaning.
* adding new uses to existing primary tags is highly sensitive and 
should usually be discussed first.  Creating a new tag is almost always 
a better idea.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[François Lacombe]

Hi all,

Consecutively to edits of page
https://wiki.openstreetmap.org/w/index.php?title=Tag:waterway%3Dcanal=history
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
purposes?

All the best

François

2018-07-03 0:37 GMT+02:00 Volker Schmidt :

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

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

[Volker Schmidt]

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