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 <colin.sm...@xs4all.nl> 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 <colin.sm...@xs4all.nl>
>> 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 <colin.sm...@xs4all.nl> 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
>
> _______________________________________________
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
