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

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

[Multi Modaal]

Hi all,


>François
>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
purposes?
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:

https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot

https://wiki.openstreetmap.org/wiki/Tag:route%3Dbicycle

https://wiki.openstreetmap.org/wiki/Tag:route%3Dhorse



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.
Personally
> 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 

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