Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Dave Swarthout]

Unfortunately, this topic has gotten split into two threads making it
difficult to follow. In trying to summarize, let's not be overly concerned
with rendering issues or whether this scheme can be fully modeled on OSM.
We can deal with rapids, hazards, etc., using existing tagging or develop
new tagging schemes later. That goes for discussions about using relations
to model "overlaps". I'm trying to tag a river feature, a named bend in the
waterway. Can we decide about the scenario we're currently working with?

This example uses the colon ":" as a separator for different parts of the
keys rather than mixing it with the underscore character "_".

> waterway=river
> name=Tanana River
> waterway:section=bend
> waterway:section:name=Harper Bend

Pros and cons (subject to the limitations I mentioned)?

On Sun, Sep 30, 2018 at 8:13 AM Joseph Eisenberg 
wrote:

> I believe rapids always will cover the width of a river, just like a
> waterfall. Rapids form where the channel of a river heads downhill at a
> steeper grade, and water wants to follow The exception would be a river
> that has split in two at a flat spot up above the rapids (eg the Niagra
> river splits around an island before the Canadian and American falls) but
> in that case there should be 2 ways, one as main_stream and one as
> side_stream. There will still be a rapid or waterfall on each part of the
> river where it crosses the area of different geology, though the location
> might be different in this case.
>
> On Sat, Sep 29, 2018 at 10:39 PM Colin Smale 
> wrote:
>
>> I would prefer to stay close to real life if possible. We should
>> choose/adapt our tagging model to match reality, and not try to force
>> reality into unnatural boxes. If real life has the possibility of overlaps,
>> we should allow for that. Making the way for "river_feature" colinear with
>> any existing "centre line" is an artificial construct for possible
>> convenience. But if it starts limiting our ability to model the world, then
>> we should abandon that idea. We should not be feeling sorry for the poor
>> old database because it has to store a few extra nodes. The name of a given
>> river section is merely a convenience to a canoeist, whereas warnings about
>> rapids are slightly more important (I imagine, anyway). I suppose there
>> would be nothing wrong with having a river section labelled with a name (as
>> we are discussing here), and in addition, information for the canoeist. How
>> is this latter information currently modelled in OSM? Is it possible that
>> "rapids" or whatever do not cover the whole width of the river? In that
>> case they will need their own polygon. Maybe we should not try to mix up
>> "rapids" etc with the naming of sections.
>>
>>
>> On 2018-09-29 14:22, Yves wrote:
>>
>> For the rare case a 'section' should have two names, the smallest part
>> can have it I guess.
>> Instead of section or reach, there's :part, like in building:part.
>>
>> Le 29 septembre 2018 11:24:29 GMT+02:00, Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> a écrit :
>>>
>>> Practically, if the ways overlap, it may be hard to render the name
>>> labels and interpret the data.
>>>
>>> I'm imagining a routing app for boaters or paddlers. It could announce
>>> the name of each new reach, bend and section, and also warn of hazards:
>>> "bridge in 400 meters", "Rock hazard", "rapids ahead, grade 2". For this
>>> case, it would be harder to use river sections that overlap.
>>>
>>> Also, if you wanted to download all the parts of the river into a
>>> spreadsheet, it wouldn't be easy to analyze the data if ways overlap.
>>>
>>> I do like Yves's suggested tags, for this reason
>>> On Sat, Sep 29, 2018 at 5:19 PM Colin Smale 
>>> wrote:
>>>
 river_feature would be fine as well as it would imply that it doesn't
 need to be a linear feature, a node would also be OK (for small named bays
 etc?)

 Lets have a go at agreeing the basic principles of what we are trying
 to achieve.
 * there can be contiguous linear sections of a river which can have
 names
 * there can be small features with names, such as small bays which can
 better be represented by a node
 * they can be "straight" (for example "reaches") or "curved" (for
 example "bends")
 * they can (partially) overlap each other, and there may be gaps (there
 may not be a clear, sharp transition from one section to the next)
 * in the case of linear feature, they encompass the entire width of the
 river and are not just a 2D line
 * for "river", read (river OR stream OR drain OR...)

 This is pointing towards:
 * a way along the centre line of the river (colinear with the
 main_stream lines?) OR a node for smaller / non-linear features
 * waterway=river_feature
 * river_feature={reach,bend,bay,...}
 * name=*


 I would like this to be applicable to lakes as well (why not?) but it's
 difficult to see how a linear 

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Joseph Eisenberg]

I believe rapids always will cover the width of a river, just like a
waterfall. Rapids form where the channel of a river heads downhill at a
steeper grade, and water wants to follow The exception would be a river
that has split in two at a flat spot up above the rapids (eg the Niagra
river splits around an island before the Canadian and American falls) but
in that case there should be 2 ways, one as main_stream and one as
side_stream. There will still be a rapid or waterfall on each part of the
river where it crosses the area of different geology, though the location
might be different in this case.

On Sat, Sep 29, 2018 at 10:39 PM Colin Smale  wrote:

> I would prefer to stay close to real life if possible. We should
> choose/adapt our tagging model to match reality, and not try to force
> reality into unnatural boxes. If real life has the possibility of overlaps,
> we should allow for that. Making the way for "river_feature" colinear with
> any existing "centre line" is an artificial construct for possible
> convenience. But if it starts limiting our ability to model the world, then
> we should abandon that idea. We should not be feeling sorry for the poor
> old database because it has to store a few extra nodes. The name of a given
> river section is merely a convenience to a canoeist, whereas warnings about
> rapids are slightly more important (I imagine, anyway). I suppose there
> would be nothing wrong with having a river section labelled with a name (as
> we are discussing here), and in addition, information for the canoeist. How
> is this latter information currently modelled in OSM? Is it possible that
> "rapids" or whatever do not cover the whole width of the river? In that
> case they will need their own polygon. Maybe we should not try to mix up
> "rapids" etc with the naming of sections.
>
>
> On 2018-09-29 14:22, Yves wrote:
>
> For the rare case a 'section' should have two names, the smallest part can
> have it I guess.
> Instead of section or reach, there's :part, like in building:part.
>
> Le 29 septembre 2018 11:24:29 GMT+02:00, Joseph Eisenberg <
> joseph.eisenb...@gmail.com> a écrit :
>>
>> Practically, if the ways overlap, it may be hard to render the name
>> labels and interpret the data.
>>
>> I'm imagining a routing app for boaters or paddlers. It could announce
>> the name of each new reach, bend and section, and also warn of hazards:
>> "bridge in 400 meters", "Rock hazard", "rapids ahead, grade 2". For this
>> case, it would be harder to use river sections that overlap.
>>
>> Also, if you wanted to download all the parts of the river into a
>> spreadsheet, it wouldn't be easy to analyze the data if ways overlap.
>>
>> I do like Yves's suggested tags, for this reason
>> On Sat, Sep 29, 2018 at 5:19 PM Colin Smale 
>> wrote:
>>
>>> river_feature would be fine as well as it would imply that it doesn't
>>> need to be a linear feature, a node would also be OK (for small named bays
>>> etc?)
>>>
>>> Lets have a go at agreeing the basic principles of what we are trying to
>>> achieve.
>>> * there can be contiguous linear sections of a river which can have names
>>> * there can be small features with names, such as small bays which can
>>> better be represented by a node
>>> * they can be "straight" (for example "reaches") or "curved" (for
>>> example "bends")
>>> * they can (partially) overlap each other, and there may be gaps (there
>>> may not be a clear, sharp transition from one section to the next)
>>> * in the case of linear feature, they encompass the entire width of the
>>> river and are not just a 2D line
>>> * for "river", read (river OR stream OR drain OR...)
>>>
>>> This is pointing towards:
>>> * a way along the centre line of the river (colinear with the
>>> main_stream lines?) OR a node for smaller / non-linear features
>>> * waterway=river_feature
>>> * river_feature={reach,bend,bay,...}
>>> * name=*
>>>
>>>
>>> I would like this to be applicable to lakes as well (why not?) but it's
>>> difficult to see how a linear feature would apply to a lake. Any comments?
>>>
>>> There was a suggestion that we should re-use existing flow lines and not
>>> superimpose new ways. This would not allow for the fact that two linear
>>> features may overlap - the end of a "bend" may overlap with the first bit
>>> of a "reach" for example. The extent of these features may be well defined,
>>> but they may not be so sharp. My thought is that this freedom to allow
>>> overlaps is important. Any comments?
>>>
>>> On 2018-09-29 00:11, Graeme Fitzpatrick wrote:
>>>
>>>
>>> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote:
>>>
 The point of raising the "reach" business it to help abstracting the
 proposed tagging model to make it more generic. If we consolidate all the
 thoughts expressed so far, we can say that:
 * there can be contiguous linear sections of a river which can have
 names
 * they can be "straight" (for example "reaches") or "curved" (for
 example 

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Graeme Fitzpatrick]

On Sat, 29 Sep 2018 at 18:19, Colin Smale  wrote:

> I would like this to be applicable to lakes as well (why not?) but it's
> difficult to see how a linear feature would apply to a lake. Any comments?
>
How about permanent "lanes" (moored rows of buoys) for rowing races /
practice - not sure how you'd name it though?

On Sat, 29 Sep 2018 at 23:39, Colin Smale  wrote:

> How is this latter information currently modelled in OSM? Is it possible
> that "rapids" or whatever do not cover the whole width of the river? In
> that case they will need their own polygon. Maybe we should not try to mix
> up "rapids" etc with the naming of sections.
>
Here are several examples that I noticed while working on one of our local
Creeks recently - which is certainly *not* white water! :-)

https://www.openstreetmap.org/node/5434480021#map=19/-28.09408/153.46106

https://www.openstreetmap.org/node/5434480020

https://www.openstreetmap.org/node/5434480022

https://www.openstreetmap.org/node/5434480023

Unfortunately, none of these render on the standard map - they're only
visible in edit mode (at least in iD?)

Thanks

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

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Colin Smale]

I would prefer to stay close to real life if possible. We should
choose/adapt our tagging model to match reality, and not try to force
reality into unnatural boxes. If real life has the possibility of
overlaps, we should allow for that. Making the way for "river_feature"
colinear with any existing "centre line" is an artificial construct for
possible convenience. But if it starts limiting our ability to model the
world, then we should abandon that idea. We should not be feeling sorry
for the poor old database because it has to store a few extra nodes. The
name of a given river section is merely a convenience to a canoeist,
whereas warnings about rapids are slightly more important (I imagine,
anyway). I suppose there would be nothing wrong with having a river
section labelled with a name (as we are discussing here), and in
addition, information for the canoeist. How is this latter information
currently modelled in OSM? Is it possible that "rapids" or whatever do
not cover the whole width of the river? In that case they will need
their own polygon. Maybe we should not try to mix up "rapids" etc with
the naming of sections. 

On 2018-09-29 14:22, Yves wrote:

> For the rare case a 'section' should have two names, the smallest part can 
> have it I guess.
> Instead of section or reach, there's :part, like in building:part. 
> 
> Le 29 septembre 2018 11:24:29 GMT+02:00, Joseph Eisenberg 
>  a écrit : Practically, if the ways overlap, it 
> may be hard to render the name labels and interpret the data. 
> 
> I'm imagining a routing app for boaters or paddlers. It could announce the 
> name of each new reach, bend and section, and also warn of hazards: "bridge 
> in 400 meters", "Rock hazard", "rapids ahead, grade 2". For this case, it 
> would be harder to use river sections that overlap.
> 
> Also, if you wanted to download all the parts of the river into a 
> spreadsheet, it wouldn't be easy to analyze the data if ways overlap.
> 
> I do like Yves's suggested tags, for this reason
> 
> On Sat, Sep 29, 2018 at 5:19 PM Colin Smale  wrote: 
> 
> river_feature would be fine as well as it would imply that it doesn't need to 
> be a linear feature, a node would also be OK (for small named bays etc?)
> 
> Lets have a go at agreeing the basic principles of what we are trying to 
> achieve.  
> 
> * there can be contiguous linear sections of a river which can have names 
> * there can be small features with names, such as small bays which can better 
> be represented by a node 
> * they can be "straight" (for example "reaches") or "curved" (for example 
> "bends") 
> * they can (partially) overlap each other, and there may be gaps (there may 
> not be a clear, sharp transition from one section to the next) 
> * in the case of linear feature, they encompass the entire width of the river 
> and are not just a 2D line 
> * for "river", read (river OR stream OR drain OR...) 
> 
> This is pointing towards: 
> * a way along the centre line of the river (colinear with the main_stream 
> lines?) OR a node for smaller / non-linear features 
> * waterway=river_feature 
> * river_feature={reach,bend,bay,...} 
> 
> * name=* 
> 
> I would like this to be applicable to lakes as well (why not?) but it's 
> difficult to see how a linear feature would apply to a lake. Any comments? 
> 
> There was a suggestion that we should re-use existing flow lines and not 
> superimpose new ways. This would not allow for the fact that two linear 
> features may overlap - the end of a "bend" may overlap with the first bit of 
> a "reach" for example. The extent of these features may be well defined, but 
> they may not be so sharp. My thought is that this freedom to allow overlaps 
> is important. Any comments? 
> 
> On 2018-09-29 00:11, Graeme Fitzpatrick wrote: 
> 
> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote: 
> 
> The point of raising the "reach" business it to help abstracting the proposed 
> tagging model to make it more generic. If we consolidate all the thoughts 
> expressed so far, we can say that:
> 
> * there can be contiguous linear sections of a river which can have names 
> * they can be "straight" (for example "reaches") or "curved" (for example 
> "bends") 
> * they can (partially) overlap each other, and there may be gaps (there may 
> not be a clear, sharp transition from one section to the next) 
> * they encompass the entire width of the river and are not just a 2D line 
> 
> This is pointing towards: 
> * a way along the centre line of the river (colinear with the main_stream 
> lines?) 
> * waterway=river_section 
> * river_section={reach,bend,...} 
> * name=* 
> 
> Liking your train of thought Colin. 
> 
> Just wondering, perhaps =river_feature? 
> 
> I'm not certain about "they encompass the entire width of the river" though? 
> Would that then exclude things like _"The Deep Hole"_ & _"17 Mile Rocks"_, 
> which are both named spots that I can point out on a map? 
> 
> Thanks 
> 
> Graeme  
> 

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Yves]

For the rare case a 'section' should have two names, the smallest part can have 
it I guess.
Instead of section or reach, there's :part, like in building:part. 

Le 29 septembre 2018 11:24:29 GMT+02:00, Joseph Eisenberg 
 a écrit :
>Practically, if the ways overlap, it may be hard to render the name
>labels
>and interpret the data.
>
>I’m imagining a routing app for boaters or paddlers. It could announce
>the
>name of each new reach, bend and section, and also warn of hazards:
>“bridge
>in 400 meters”, “Rock hazard”, “rapids ahead, grade 2”. For this case,
>it
>would be harder to use river sections that overlap.
>
>Also, if you wanted to download all the parts of the river into a
>spreadsheet, it wouldn’t be easy to analyze the data if ways overlap.
>
>I do like Yves’s suggested tags, for this reason
>On Sat, Sep 29, 2018 at 5:19 PM Colin Smale 
>wrote:
>
>> river_feature would be fine as well as it would imply that it doesn't
>need
>> to be a linear feature, a node would also be OK (for small named bays
>etc?)
>>
>> Lets have a go at agreeing the basic principles of what we are trying
>to
>> achieve.
>> * there can be contiguous linear sections of a river which can have
>names
>> * there can be small features with names, such as small bays which
>can
>> better be represented by a node
>> * they can be "straight" (for example "reaches") or "curved" (for
>example
>> "bends")
>> * they can (partially) overlap each other, and there may be gaps
>(there
>> may not be a clear, sharp transition from one section to the next)
>> * in the case of linear feature, they encompass the entire width of
>the
>> river and are not just a 2D line
>> * for "river", read (river OR stream OR drain OR...)
>>
>> This is pointing towards:
>> * a way along the centre line of the river (colinear with the
>main_stream
>> lines?) OR a node for smaller / non-linear features
>> * waterway=river_feature
>> * river_feature={reach,bend,bay,...}
>> * name=*
>>
>>
>> I would like this to be applicable to lakes as well (why not?) but
>it's
>> difficult to see how a linear feature would apply to a lake. Any
>comments?
>>
>> There was a suggestion that we should re-use existing flow lines and
>not
>> superimpose new ways. This would not allow for the fact that two
>linear
>> features may overlap - the end of a "bend" may overlap with the first
>bit
>> of a "reach" for example. The extent of these features may be well
>defined,
>> but they may not be so sharp. My thought is that this freedom to
>allow
>> overlaps is important. Any comments?
>>
>> On 2018-09-29 00:11, Graeme Fitzpatrick wrote:
>>
>>
>> On Sat, 29 Sep 2018 at 06:32, Colin Smale 
>wrote:
>>
>>> The point of raising the "reach" business it to help abstracting the
>>> proposed tagging model to make it more generic. If we consolidate
>all the
>>> thoughts expressed so far, we can say that:
>>> * there can be contiguous linear sections of a river which can have
>names
>>> * they can be "straight" (for example "reaches") or "curved" (for
>example
>>> "bends")
>>> * they can (partially) overlap each other, and there may be gaps
>(there
>>> may not be a clear, sharp transition from one section to the next)
>>> * they encompass the entire width of the river and are not just a 2D
>line
>>>
>>
>>
>>> This is pointing towards:
>>> * a way along the centre line of the river (colinear with the
>main_stream
>>> lines?)
>>> * waterway=river_section
>>> * river_section={reach,bend,...}
>>> * name=*
>>>
>>
>> Liking your train of thought Colin.
>>
>> Just wondering, perhaps =river_feature?
>>
>> I'm not certain about "they encompass the entire width of the river"
>though?
>> Would that then exclude things like *"The Deep Hole"* & *"17 Mile
>Rocks"*,
>> which are both named spots that I can point out on a map?
>>
>> Thanks
>>
>> Graeme
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Joseph Eisenberg]

Practically, if the ways overlap, it may be hard to render the name labels
and interpret the data.

I’m imagining a routing app for boaters or paddlers. It could announce the
name of each new reach, bend and section, and also warn of hazards: “bridge
in 400 meters”, “Rock hazard”, “rapids ahead, grade 2”. For this case, it
would be harder to use river sections that overlap.

Also, if you wanted to download all the parts of the river into a
spreadsheet, it wouldn’t be easy to analyze the data if ways overlap.

I do like Yves’s suggested tags, for this reason
On Sat, Sep 29, 2018 at 5:19 PM Colin Smale  wrote:

> river_feature would be fine as well as it would imply that it doesn't need
> to be a linear feature, a node would also be OK (for small named bays etc?)
>
> Lets have a go at agreeing the basic principles of what we are trying to
> achieve.
> * there can be contiguous linear sections of a river which can have names
> * there can be small features with names, such as small bays which can
> better be represented by a node
> * they can be "straight" (for example "reaches") or "curved" (for example
> "bends")
> * they can (partially) overlap each other, and there may be gaps (there
> may not be a clear, sharp transition from one section to the next)
> * in the case of linear feature, they encompass the entire width of the
> river and are not just a 2D line
> * for "river", read (river OR stream OR drain OR...)
>
> This is pointing towards:
> * a way along the centre line of the river (colinear with the main_stream
> lines?) OR a node for smaller / non-linear features
> * waterway=river_feature
> * river_feature={reach,bend,bay,...}
> * name=*
>
>
> I would like this to be applicable to lakes as well (why not?) but it's
> difficult to see how a linear feature would apply to a lake. Any comments?
>
> There was a suggestion that we should re-use existing flow lines and not
> superimpose new ways. This would not allow for the fact that two linear
> features may overlap - the end of a "bend" may overlap with the first bit
> of a "reach" for example. The extent of these features may be well defined,
> but they may not be so sharp. My thought is that this freedom to allow
> overlaps is important. Any comments?
>
> On 2018-09-29 00:11, Graeme Fitzpatrick wrote:
>
>
> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote:
>
>> The point of raising the "reach" business it to help abstracting the
>> proposed tagging model to make it more generic. If we consolidate all the
>> thoughts expressed so far, we can say that:
>> * there can be contiguous linear sections of a river which can have names
>> * they can be "straight" (for example "reaches") or "curved" (for example
>> "bends")
>> * they can (partially) overlap each other, and there may be gaps (there
>> may not be a clear, sharp transition from one section to the next)
>> * they encompass the entire width of the river and are not just a 2D line
>>
>
>
>> This is pointing towards:
>> * a way along the centre line of the river (colinear with the main_stream
>> lines?)
>> * waterway=river_section
>> * river_section={reach,bend,...}
>> * name=*
>>
>
> Liking your train of thought Colin.
>
> Just wondering, perhaps =river_feature?
>
> I'm not certain about "they encompass the entire width of the river" though?
> Would that then exclude things like *"The Deep Hole"* & *"17 Mile Rocks"*,
> which are both named spots that I can point out on a map?
>
> Thanks
>
> Graeme
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Dave Swarthout]

Yes, yes, of course. Quite right, Yves, and Martin.

>> waterway=river
>> name=Tanana River
>> waterway=section
>> section=bend
>> section:name=Harper Bend
>You can't use waterway=section + waterway=river on the same way, and you
>shouldn't map overlapping ways for obvious reasons.

I made that same argument myself earlier and then broke my own rule
immediately. LOL

Yves suggests this scenario:

waterway=river
name=Tanana River
waterway:section=bend
waterway:section_name=Harper Bend

Which I like, except for the way the last tag is written. I would prefer
waterway:section:name=Harper Bend

I don't like mixing the uses of "_" and ":"
The way these two delimiters have been used in OSM has always seemed
muddled to me.

Colin suggested we agree on the goals of this project and wrote:

* there can be contiguous linear sections of a river which can have names
* there can be small features with names, such as small bays which can
better be represented by a node
* they can be "straight" (for example "reaches") or "curved" (for example
"bends")
* they can (partially) overlap each other, and there may be gaps (there may
not be a clear, sharp transition from one section to the next)
* in the case of linear feature, they encompass the entire width of the
river and are not just a 2D line
* for "river", read (river OR stream OR drain OR...)

These indeed are the goals of this discussion as I see them. The last of
these is an attempt to make the tagging consistent for several varieties of
waterway which is why, IMO, we use the waterway key instead of river or
stream, etc.

So, what's next?






On Sat, Sep 29, 2018 at 3:19 PM Colin Smale  wrote:

> river_feature would be fine as well as it would imply that it doesn't need
> to be a linear feature, a node would also be OK (for small named bays etc?)
>
> Lets have a go at agreeing the basic principles of what we are trying to
> achieve.
> * there can be contiguous linear sections of a river which can have names
> * there can be small features with names, such as small bays which can
> better be represented by a node
> * they can be "straight" (for example "reaches") or "curved" (for example
> "bends")
> * they can (partially) overlap each other, and there may be gaps (there
> may not be a clear, sharp transition from one section to the next)
> * in the case of linear feature, they encompass the entire width of the
> river and are not just a 2D line
> * for "river", read (river OR stream OR drain OR...)
>
> This is pointing towards:
> * a way along the centre line of the river (colinear with the main_stream
> lines?) OR a node for smaller / non-linear features
> * waterway=river_feature
> * river_feature={reach,bend,bay,...}
> * name=*
>
>
> I would like this to be applicable to lakes as well (why not?) but it's
> difficult to see how a linear feature would apply to a lake. Any comments?
>
> There was a suggestion that we should re-use existing flow lines and not
> superimpose new ways. This would not allow for the fact that two linear
> features may overlap - the end of a "bend" may overlap with the first bit
> of a "reach" for example. The extent of these features may be well defined,
> but they may not be so sharp. My thought is that this freedom to allow
> overlaps is important. Any comments?
>
> On 2018-09-29 00:11, Graeme Fitzpatrick wrote:
>
>
> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote:
>
>> The point of raising the "reach" business it to help abstracting the
>> proposed tagging model to make it more generic. If we consolidate all the
>> thoughts expressed so far, we can say that:
>> * there can be contiguous linear sections of a river which can have names
>> * they can be "straight" (for example "reaches") or "curved" (for example
>> "bends")
>> * they can (partially) overlap each other, and there may be gaps (there
>> may not be a clear, sharp transition from one section to the next)
>> * they encompass the entire width of the river and are not just a 2D line
>>
>
>
>> This is pointing towards:
>> * a way along the centre line of the river (colinear with the main_stream
>> lines?)
>> * waterway=river_section
>> * river_section={reach,bend,...}
>> * name=*
>>
>
> Liking your train of thought Colin.
>
> Just wondering, perhaps =river_feature?
>
> I'm not certain about "they encompass the entire width of the river" though?
> Would that then exclude things like *"The Deep Hole"* & *"17 Mile Rocks"*,
> which are both named spots that I can point out on a map?
>
> Thanks
>
> Graeme
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Colin Smale]

river_feature would be fine as well as it would imply that it doesn't
need to be a linear feature, a node would also be OK (for small named
bays etc?)

Lets have a go at agreeing the basic principles of what we are trying to
achieve.  

* there can be contiguous linear sections of a river which can have
names 
* there can be small features with names, such as small bays which can
better be represented by a node 
* they can be "straight" (for example "reaches") or "curved" (for
example "bends") 
* they can (partially) overlap each other, and there may be gaps (there
may not be a clear, sharp transition from one section to the next) 
* in the case of linear feature, they encompass the entire width of the
river and are not just a 2D line 
* for "river", read (river OR stream OR drain OR...) 

This is pointing towards: 
* a way along the centre line of the river (colinear with the
main_stream lines?) OR a node for smaller / non-linear features 
* waterway=river_feature 
* river_feature={reach,bend,bay,...} 

* name=* 

I would like this to be applicable to lakes as well (why not?) but it's
difficult to see how a linear feature would apply to a lake. Any
comments? 

There was a suggestion that we should re-use existing flow lines and not
superimpose new ways. This would not allow for the fact that two linear
features may overlap - the end of a "bend" may overlap with the first
bit of a "reach" for example. The extent of these features may be well
defined, but they may not be so sharp. My thought is that this freedom
to allow overlaps is important. Any comments? 

On 2018-09-29 00:11, Graeme Fitzpatrick wrote:

> On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote: 
> 
>> The point of raising the "reach" business it to help abstracting the 
>> proposed tagging model to make it more generic. If we consolidate all the 
>> thoughts expressed so far, we can say that:
>> 
>> * there can be contiguous linear sections of a river which can have names 
>> * they can be "straight" (for example "reaches") or "curved" (for example 
>> "bends") 
>> * they can (partially) overlap each other, and there may be gaps (there may 
>> not be a clear, sharp transition from one section to the next) 
>> * they encompass the entire width of the river and are not just a 2D line
> 
>> This is pointing towards: 
>> * a way along the centre line of the river (colinear with the main_stream 
>> lines?) 
>> * waterway=river_section 
>> * river_section={reach,bend,...} 
>> * name=*
> 
> Liking your train of thought Colin. 
> 
> Just wondering, perhaps =river_feature? 
> 
> I'm not certain about "they encompass the entire width of the river" though? 
> Would that then exclude things like _"The Deep Hole"_ & _"17 Mile Rocks"_, 
> which are both named spots that I can point out on a map? 
> 
> Thanks 
> 
> Graeme  
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[yves]

Le 29. 09. 18 à 00:53, Dave Swarthout a écrit

waterway=river
name=Tanana River
waterway=section
section=bend
section:name=Harper Bend
You can't use waterway=section + waterway=river on the same way, and you 
shouldn't map overlapping ways for obvious reasons.


But you can split a waterway=river in how many smaller way you want to 
add a subtag.

To take the whitewater proposal method, this could be :

waterway=river
name=Tanana River
waterway:section=bend
waterway:section_name=Harper Bend

or

waterway=river
name=Tanana River
river:section=bend
river:section_name=Harper Bend

but the former allow for canal, ditches and else.
Yves

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

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[yves]

Although the whitewater proposal is here for a long time, and it being 
the only documented way to tag kayaking/canoe practise on whitewater, it 
is seldom used.
Probably there is simply not enough people interested in those sports 
and Openstreetmap at the same time. Maybe in a few years there will be 
enough people interested so that a RFC + vote would make any sense, for 
now I think it's best to let it alone as a documentation.






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

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Dave Swarthout]

@Joseph,

>I suppose section=* with railway=* can be treated differently than
section=* with waterway=section, but it’s not ideaI

On second thought, I agree, it's probably not a big issue.

>These proposals all appear to keep one way for the waterway=river, with
the way split for each long section. So a node is named for a short hazard
or rapid, but longer sections are named on the same way >as the river.
That’s why they choose to use :section_name=* instead of just name=*

That's what I was getting at earlier. The river name must stay the same
even though the various "sections" will often have different names. Also,
if one needed to name a shorter section within a longer section, you could
use a relation. Whether the shorter "inner" sections would ever be rendered
is another question but certainly custom maps could be programmed to take
these sections and their names into account. Another observation that
raises yet another question is why the whitewater proposal uses
section_name rather than section:name as the key. AFAIK, the underscore
character is used to connect two words that are meant to be treated as one,
e.g., man_made, while the colon character ":", is often used to
differentiate different subkeys of a major key, e.g., source:position or
source:name. How do you see this?

I am not a whitewater person but even if I were, I wouldn't volunteer to
take on such a project. I hate writing anything in the Wiki. It's a
difficult and arcane piece of software IMO and I have no desire to wade in
and learn it. Life's too short.

Dave

On Sat, Sep 29, 2018 at 7:07 AM Joseph Eisenberg 
wrote:

> I suppose section=* with railway=* can be treated differently than
> section=* with waterway=section, but it’s not ideal.
>
> I spent some time looking at the whitewater proposals, which introduced
> tags for whitewater:section_name and whitewater:rapid_name, in addition to
> whitewater grades for rapids and river sections, and POIs for river
> hazards, put-in points and take-out points for rafts/kayaks/canoes:
> https://wiki.openstreetmap.org/wiki/Whitewater_sports
>
> These proposals all appear to keep one way for the waterway=river, with
> the way split for each long section. So a node is named for a short hazard
> or rapid, but longer sections are named on the same way as the river.
> That’s why they choose to use :section_name=* instead of just name=*
>
> There is some value to this approach, because it won’t lead to multiple
> overlapping ways for each river. But it wouldn’t be possible to name a long
> section and a shorter reach or bend which is part of a long river section,
> except by tagging a node only, without creating separate ways.
>
> It used to be possible to see the whitewater tags on a layer at
> openseamap.org but it is no longer offered.
>
> Dave, if you have an interest in whitewater sports, there is a great
> opportunity for someone to revive one of the proposals and get it approved,
> in addition to tags that could describe flat water rivers and canals for
> general boating. But it looks like a big project.
>
>
> On Sat, Sep 29, 2018 at 8:20 AM Dave Swarthout 
> wrote:
>
>> One other thing about the section key I just learned from Taginfo.
>> Although undocumented it has had some use already to describe sections of a
>> railway. So maybe we need to make it easier to distinguish between those
>> uses? Or maybe not.
>>
>>
>>
>>
>> On Sat, Sep 29, 2018 at 5:53 AM Dave Swarthout 
>> wrote:
>>
>>> It appears I was too hasty about dismissing the reach argument. Yes,
>>> that makes sense Colin. And Joseph's suggestion to make it more general
>>> sounds good too. I think the name part needs to be set up to distinguish
>>> the name of the bend or reach from that of the river because both are valid
>>> for any section. The hierarchy below would fill the bill and more than
>>> satisfy my sense of orderliness. LOL
>>>
>>> waterway=river
>>> name=Tanana River
>>> waterway=section
>>> section=bend
>>> section:name=Harper Bend
>>>
>>> I like what we've come up with so far. Any more suggestions?
>>>
>>> Dave
>>>
>>> On Sat, Sep 29, 2018 at 5:15 AM Joseph Eisenberg <
>>> joseph.eisenb...@gmail.com> wrote:
>>>
 Do canals have named sections?

 Waterway=section would work for canals too, if there are such a thing
 as canal reaches or sections or bends

 On Sat, Sep 29, 2018 at 5:32 AM Colin Smale 
 wrote:

> On 2018-09-28 07:37, Dave Swarthout wrote:
>
> The discussion about the definition of "reach" is interesting but IMO
> it's slightly off topic.  Perhaps, because of those differences in its
> interpretation, we would be best served by not using the term at all.
>
>
> The point of raising the "reach" business it to help abstracting the
> proposed tagging model to make it more generic. If we consolidate all the
> thoughts expressed so far, we can say that:
> * there can be contiguous linear sections of a river which can have
> 

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Joseph Eisenberg]

I suppose section=* with railway=* can be treated differently than
section=* with waterway=section, but it’s not ideal.

I spent some time looking at the whitewater proposals, which introduced
tags for whitewater:section_name and whitewater:rapid_name, in addition to
whitewater grades for rapids and river sections, and POIs for river
hazards, put-in points and take-out points for rafts/kayaks/canoes:
https://wiki.openstreetmap.org/wiki/Whitewater_sports

These proposals all appear to keep one way for the waterway=river, with the
way split for each long section. So a node is named for a short hazard or
rapid, but longer sections are named on the same way as the river. That’s
why they choose to use :section_name=* instead of just name=*

There is some value to this approach, because it won’t lead to multiple
overlapping ways for each river. But it wouldn’t be possible to name a long
section and a shorter reach or bend which is part of a long river section,
except by tagging a node only, without creating separate ways.

It used to be possible to see the whitewater tags on a layer at
openseamap.org but it is no longer offered.

Dave, if you have an interest in whitewater sports, there is a great
opportunity for someone to revive one of the proposals and get it approved,
in addition to tags that could describe flat water rivers and canals for
general boating. But it looks like a big project.


On Sat, Sep 29, 2018 at 8:20 AM Dave Swarthout 
wrote:

> One other thing about the section key I just learned from Taginfo.
> Although undocumented it has had some use already to describe sections of a
> railway. So maybe we need to make it easier to distinguish between those
> uses? Or maybe not.
>
>
>
>
> On Sat, Sep 29, 2018 at 5:53 AM Dave Swarthout 
> wrote:
>
>> It appears I was too hasty about dismissing the reach argument. Yes, that
>> makes sense Colin. And Joseph's suggestion to make it more general sounds
>> good too. I think the name part needs to be set up to distinguish the name
>> of the bend or reach from that of the river because both are valid for any
>> section. The hierarchy below would fill the bill and more than satisfy my
>> sense of orderliness. LOL
>>
>> waterway=river
>> name=Tanana River
>> waterway=section
>> section=bend
>> section:name=Harper Bend
>>
>> I like what we've come up with so far. Any more suggestions?
>>
>> Dave
>>
>> On Sat, Sep 29, 2018 at 5:15 AM Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> Do canals have named sections?
>>>
>>> Waterway=section would work for canals too, if there are such a thing as
>>> canal reaches or sections or bends
>>>
>>> On Sat, Sep 29, 2018 at 5:32 AM Colin Smale 
>>> wrote:
>>>
 On 2018-09-28 07:37, Dave Swarthout wrote:

 The discussion about the definition of "reach" is interesting but IMO
 it's slightly off topic.  Perhaps, because of those differences in its
 interpretation, we would be best served by not using the term at all.


 The point of raising the "reach" business it to help abstracting the
 proposed tagging model to make it more generic. If we consolidate all the
 thoughts expressed so far, we can say that:
 * there can be contiguous linear sections of a river which can have
 names
 * they can be "straight" (for example "reaches") or "curved" (for
 example "bends")
 * they can (partially) overlap each other, and there may be gaps (there
 may not be a clear, sharp transition from one section to the next)
 * they encompass the entire width of the river and are not just a 2D
 line

 This is pointing towards:
 * a way along the centre line of the river (colinear with the
 main_stream lines?)
 * waterway=river_section
 * river_section={reach,bend,...}
 * name=*

 Is this a basis that we can work incrementally forwards from?

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

>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> --
>> Dave Swarthout
>> Homer, Alaska
>> Chiang Mai, Thailand
>> Travel Blog at http://dswarthout.blogspot.com
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Dave Swarthout]

One other thing about the section key I just learned from Taginfo. Although
undocumented it has had some use already to describe sections of a railway.
So maybe we need to make it easier to distinguish between those uses? Or
maybe not.




On Sat, Sep 29, 2018 at 5:53 AM Dave Swarthout 
wrote:

> It appears I was too hasty about dismissing the reach argument. Yes, that
> makes sense Colin. And Joseph's suggestion to make it more general sounds
> good too. I think the name part needs to be set up to distinguish the name
> of the bend or reach from that of the river because both are valid for any
> section. The hierarchy below would fill the bill and more than satisfy my
> sense of orderliness. LOL
>
> waterway=river
> name=Tanana River
> waterway=section
> section=bend
> section:name=Harper Bend
>
> I like what we've come up with so far. Any more suggestions?
>
> Dave
>
> On Sat, Sep 29, 2018 at 5:15 AM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> Do canals have named sections?
>>
>> Waterway=section would work for canals too, if there are such a thing as
>> canal reaches or sections or bends
>>
>> On Sat, Sep 29, 2018 at 5:32 AM Colin Smale 
>> wrote:
>>
>>> On 2018-09-28 07:37, Dave Swarthout wrote:
>>>
>>> The discussion about the definition of "reach" is interesting but IMO
>>> it's slightly off topic.  Perhaps, because of those differences in its
>>> interpretation, we would be best served by not using the term at all.
>>>
>>>
>>> The point of raising the "reach" business it to help abstracting the
>>> proposed tagging model to make it more generic. If we consolidate all the
>>> thoughts expressed so far, we can say that:
>>> * there can be contiguous linear sections of a river which can have names
>>> * they can be "straight" (for example "reaches") or "curved" (for
>>> example "bends")
>>> * they can (partially) overlap each other, and there may be gaps (there
>>> may not be a clear, sharp transition from one section to the next)
>>> * they encompass the entire width of the river and are not just a 2D line
>>>
>>> This is pointing towards:
>>> * a way along the centre line of the river (colinear with the
>>> main_stream lines?)
>>> * waterway=river_section
>>> * river_section={reach,bend,...}
>>> * name=*
>>>
>>> Is this a basis that we can work incrementally forwards from?
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Dave Swarthout]

It appears I was too hasty about dismissing the reach argument. Yes, that
makes sense Colin. And Joseph's suggestion to make it more general sounds
good too. I think the name part needs to be set up to distinguish the name
of the bend or reach from that of the river because both are valid for any
section. The hierarchy below would fill the bill and more than satisfy my
sense of orderliness. LOL

waterway=river
name=Tanana River
waterway=section
section=bend
section:name=Harper Bend

I like what we've come up with so far. Any more suggestions?

Dave

On Sat, Sep 29, 2018 at 5:15 AM Joseph Eisenberg 
wrote:

> Do canals have named sections?
>
> Waterway=section would work for canals too, if there are such a thing as
> canal reaches or sections or bends
>
> On Sat, Sep 29, 2018 at 5:32 AM Colin Smale  wrote:
>
>> On 2018-09-28 07:37, Dave Swarthout wrote:
>>
>> The discussion about the definition of "reach" is interesting but IMO
>> it's slightly off topic.  Perhaps, because of those differences in its
>> interpretation, we would be best served by not using the term at all.
>>
>>
>> The point of raising the "reach" business it to help abstracting the
>> proposed tagging model to make it more generic. If we consolidate all the
>> thoughts expressed so far, we can say that:
>> * there can be contiguous linear sections of a river which can have names
>> * they can be "straight" (for example "reaches") or "curved" (for example
>> "bends")
>> * they can (partially) overlap each other, and there may be gaps (there
>> may not be a clear, sharp transition from one section to the next)
>> * they encompass the entire width of the river and are not just a 2D line
>>
>> This is pointing towards:
>> * a way along the centre line of the river (colinear with the main_stream
>> lines?)
>> * waterway=river_section
>> * river_section={reach,bend,...}
>> * name=*
>>
>> Is this a basis that we can work incrementally forwards from?
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Joseph Eisenberg]

Do canals have named sections?

Waterway=section would work for canals too, if there are such a thing as
canal reaches or sections or bends

On Sat, Sep 29, 2018 at 5:32 AM Colin Smale  wrote:

> On 2018-09-28 07:37, Dave Swarthout wrote:
>
> The discussion about the definition of "reach" is interesting but IMO it's
> slightly off topic.  Perhaps, because of those differences in its
> interpretation, we would be best served by not using the term at all.
>
>
> The point of raising the "reach" business it to help abstracting the
> proposed tagging model to make it more generic. If we consolidate all the
> thoughts expressed so far, we can say that:
> * there can be contiguous linear sections of a river which can have names
> * they can be "straight" (for example "reaches") or "curved" (for example
> "bends")
> * they can (partially) overlap each other, and there may be gaps (there
> may not be a clear, sharp transition from one section to the next)
> * they encompass the entire width of the river and are not just a 2D line
>
> This is pointing towards:
> * a way along the centre line of the river (colinear with the main_stream
> lines?)
> * waterway=river_section
> * river_section={reach,bend,...}
> * name=*
>
> Is this a basis that we can work incrementally forwards from?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Graeme Fitzpatrick]

On Sat, 29 Sep 2018 at 06:32, Colin Smale  wrote:

> The point of raising the "reach" business it to help abstracting the
> proposed tagging model to make it more generic. If we consolidate all the
> thoughts expressed so far, we can say that:
> * there can be contiguous linear sections of a river which can have names
> * they can be "straight" (for example "reaches") or "curved" (for example
> "bends")
> * they can (partially) overlap each other, and there may be gaps (there
> may not be a clear, sharp transition from one section to the next)
> * they encompass the entire width of the river and are not just a 2D line
>


> This is pointing towards:
> * a way along the centre line of the river (colinear with the main_stream
> lines?)
> * waterway=river_section
> * river_section={reach,bend,...}
> * name=*
>

Liking your train of thought Colin.

Just wondering, perhaps =river_feature?

I'm not certain about "they encompass the entire width of the river" though?
Would that then exclude things like *"The Deep Hole"* & *"17 Mile Rocks"*,
which are both named spots that I can point out on a map?

Thanks

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

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Colin Smale]

On 2018-09-28 07:37, Dave Swarthout wrote:

> The discussion about the definition of "reach" is interesting but IMO it's 
> slightly off topic.  Perhaps, because of those differences in its 
> interpretation, we would be best served by not using the term at all.

The point of raising the "reach" business it to help abstracting the
proposed tagging model to make it more generic. If we consolidate all
the thoughts expressed so far, we can say that: 
* there can be contiguous linear sections of a river which can have
names 
* they can be "straight" (for example "reaches") or "curved" (for
example "bends") 
* they can (partially) overlap each other, and there may be gaps (there
may not be a clear, sharp transition from one section to the next) 
* they encompass the entire width of the river and are not just a 2D
line 

This is pointing towards: 
* a way along the centre line of the river (colinear with the
main_stream lines?) 
* waterway=river_section 
* river_section={reach,bend,...} 
* name=* 

Is this a basis that we can work incrementally forwards from?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Kevin Kenny]

On Fri, Sep 28, 2018 at 1:38 AM Dave Swarthout  wrote:
>
> The discussion about the definition of "reach" is interesting but IMO it's 
> slightly off topic.  Perhaps, because of those differences in its 
> interpretation, we would be best served by not using the term at all.

Except that I would like to see flowlines in the US tagged with their
'reach code', which is a numeric identifier in NHD and other sources
that is intended to serve as permanent idenfitication for a particular
waterway. Those cross reference to enough places that carrying the
information is useful.

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

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Dave Swarthout]

The discussion about the definition of "reach" is interesting but IMO it's
slightly off topic.  Perhaps, because of those differences in its
interpretation, we would be best served by not using the term at all.

On Fri, Sep 28, 2018 at 12:06 PM Michael Patrick 
wrote:

>
> > It would seem odd to tag a bend as a reach, as the classic definition of
> a reach is 'A portion of a river, channel, or lake which lies between two
> bends or which can be seen in one view'.
>
> Which is why the first sentence the USGS definition is: “Reach” can have 
> *slightly
> different meanings*, depending on how it is used.
>
> Since USGS is the custodian of the Geographic Names Information System
>  (GNIS) and also the hydrology
> models, they probably have a better overview of where and how it's applied
> ranging from common / historical names to strict scientific terminology.
>
> One that came to my mind which has no straightness component at all was
> the Hanford Reach on the Columbia River: *" The Hanford Reach
>  is a free-flowing section of
> the Columbia River, around 51 miles (82 km) long, in eastern Washington
> state. It is named after a large northward bend in the river's otherwise
> southbound course."*
>
> I.e. that single bend is the 'reach' :-) The Mississippi River Reaches
> 
> are hundreds of miles long and include many straight log sections, bends
> etc.
>
> I also have an U.S. Navy COLREGS book "Collision Prevention" on my table
> here where their use is exactly according to the definition you mention
> based on 'visibility'. And close to other nautical meanings like a
> sailing 'reach', being the longest clear path achievable without
> obstruction under given conditions.
>
> One source gives the 1520s as the earliest use, referring to stretches of
> water.There weren't to many straight stretches of water back then, even the
> canals in Venice and Amsterdam were pretty organic. :-)
>
> It seams it can be applied in any ad hoc way to any water between two
> locations, even nested and overlapping manners, at any scale. Precise
> ambiguity, good for OSM. :-)
>
> Michael Patrick
> Geographer
> .
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 108, Issue 162

[Michael Patrick]

> It would seem odd to tag a bend as a reach, as the classic definition of
a reach is 'A portion of a river, channel, or lake which lies between two
bends or which can be seen in one view'.

Which is why the first sentence the USGS definition is: “Reach” can
have *slightly
different meanings*, depending on how it is used.

Since USGS is the custodian of the Geographic Names Information System
 (GNIS) and also the hydrology models,
they probably have a better overview of where and how it's applied ranging
from common / historical names to strict scientific terminology.

One that came to my mind which has no straightness component at all was the
Hanford Reach on the Columbia River: *" The Hanford Reach
 is a free-flowing section of
the Columbia River, around 51 miles (82 km) long, in eastern Washington
state. It is named after a large northward bend in the river's otherwise
southbound course."*

I.e. that single bend is the 'reach' :-) The Mississippi River Reaches

are hundreds of miles long and include many straight log sections, bends
etc.

I also have an U.S. Navy COLREGS book "Collision Prevention" on my table
here where their use is exactly according to the definition you mention
based on 'visibility'. And close to other nautical meanings like a sailing
'reach', being the longest clear path achievable without obstruction under
given conditions.

One source gives the 1520s as the earliest use, referring to stretches of
water.There weren't to many straight stretches of water back then, even the
canals in Venice and Amsterdam were pretty organic. :-)

It seams it can be applied in any ad hoc way to any water between two
locations, even nested and overlapping manners, at any scale. Precise
ambiguity, good for OSM. :-)

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