[Tagging] Tagging Digest, Vol 108, Issue 162

Yves yvecai at mailbox.org
Sat Sep 29 12:22:53 UTC 2018


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.eisenberg at 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.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/f078bcdd/attachment.html>


More information about the Tagging mailing list