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
