Re: Tagging Digest, Vol 108, Issue 162

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

AlaskaDave
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

Kevin Kenny-3
On Fri, Sep 28, 2018 at 1:38 AM Dave Swarthout <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

Colin Smale
In reply to this post by AlaskaDave

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

Graeme Fitzpatrick

On Sat, 29 Sep 2018 at 06:32, Colin Smale <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

Joseph Eisenberg
In reply to this post by Colin Smale
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

AlaskaDave
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

AlaskaDave
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

AlaskaDave
@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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

Yves-2
In reply to this post by Joseph Eisenberg
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

Yves-2
In reply to this post by AlaskaDave
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

waterway bend name WAS Re: Tagging Digest, Vol 108, Issue 168

dieterdreist
In reply to this post by AlaskaDave


sent from a phone

> On 29. Sep 2018, at 00:53, Dave Swarthout <[hidden email]> wrote:
>
> 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?


this suggests 2 distinct (likely overlapping way) objects, right?

I would prefer a solution that works without duplicating the way, either by reusing it in a relation or by adding bend name properties directly on a part of the waterway (i.e. omit waterway=section tag and add all tags to the same way).

Cheers,
Martin


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: waterway bend name WAS Re: Tagging Digest, Vol 108, Issue 168

Warin
On 29/09/18 18:09, Martin Koppenhoefer wrote:

>
> sent from a phone
>
>> On 29. Sep 2018, at 00:53, Dave Swarthout <[hidden email]> wrote:
>>
>> 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?
>
> this suggests 2 distinct (likely overlapping way) objects, right?
>
> I would prefer a solution that works without duplicating the way, either by reusing it in a relation or by adding bend name properties directly on a part of the waterway (i.e. omit waterway=section tag and add all tags to the same way).
>
yves beat you to it by 1 hour 39 mins.
And he has a solution.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

Colin Smale
In reply to this post by Graeme Fitzpatrick

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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

AlaskaDave
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

Joseph Eisenberg
In reply to this post by Colin Smale
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

Yves-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging Digest, Vol 108, Issue 162

Graeme Fitzpatrick
On Sat, 29 Sep 2018 at 18:19, Colin Smale <[hidden email]> 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 <[hidden email]> 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! :-)





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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12