[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 <colin.smale at 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.smale at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180929/d1822d95/attachment.html>