<div dir="ltr"><div>Unfortunately, this topic has gotten split into two threads making it difficult to follow. In trying to summarize, let's not be overly concerned with rendering issues or whether this scheme can be fully modeled on OSM. We can deal with rapids, hazards, etc., using existing tagging or develop new tagging schemes later. That goes for discussions about using relations to model "overlaps". I'm trying to tag a river feature, a named bend in the waterway. Can we decide about the scenario we're currently working with? <br></div><div><br></div><div>This example uses the colon ":" as a separator for different parts of the keys rather than mixing it with the underscore character "_".<br></div><div><br></div><div>> waterway=river<br>> name=Tanana River<br>> waterway:section=bend<br>> waterway:section:name=Harper Bend</div><div><br></div><div>Pros and cons (subject to the limitations I mentioned)?<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Sep 30, 2018 at 8:13 AM Joseph Eisenberg <<a href="mailto:joseph.eisenberg@gmail.com" target="_blank">joseph.eisenberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="ltr">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. </div></div><div><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 29, 2018 at 10:39 PM Colin Smale <<a href="mailto:colin.smale@xs4all.nl" target="_blank">colin.smale@xs4all.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p>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.</p>
<p><br></p>
<p>On 2018-09-29 14:22, Yves wrote:</p>
<blockquote type="cite" style="padding:0 0.4em;border-left:#1010ff 2px solid;margin:0">For the rare case a 'section' should have two names, the smallest part can have it I guess.<br> Instead of section or reach, there's :part, like in building:part. <br><br>
<div class="gmail_quote">Le 29 septembre 2018 11:24:29 GMT+02:00, Joseph Eisenberg <<a href="mailto:joseph.eisenberg@gmail.com" target="_blank">joseph.eisenberg@gmail.com</a>> a écrit :
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid #cccccc;padding-left:1ex">Practically, if the ways overlap, it may be hard to render the name labels and interpret the data. <br><br>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.<br><br>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.<br><br>I do like Yves's suggested tags, for this reason<br>
<div class="gmail_quote">
<div dir="ltr">On Sat, Sep 29, 2018 at 5:19 PM Colin Smale <<a href="mailto:colin.smale@xs4all.nl" target="_blank">colin.smale@xs4all.nl</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p>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?)</p>
<div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p><span style="font-size:10pt">Lets have a go at agreeing the basic principles of what we are trying to achieve. </span></p>
</div>
<div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<div dir="ltr">* there can be contiguous linear sections of a river which can have names</div>
<div dir="ltr">* there can be small features with names, such as small bays which can better be represented by a node</div>
<div dir="ltr">* they can be "straight" (for example "reaches") or "curved" (for example "bends")</div>
<div dir="ltr">* 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)</div>
<div dir="ltr">* in the case of linear feature, they encompass the entire width of the river and are not just a 2D line</div>
<div dir="ltr">* for "river", read (river OR stream OR drain OR...)</div>
</div>
<div> </div>
<div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<div dir="ltr">This is pointing towards:</div>
<div dir="ltr">* a way along the centre line of the river (colinear with the main_stream lines?) OR a node for smaller / non-linear features</div>
<div dir="ltr">* waterway=river_feature</div>
<div dir="ltr">* river_feature={reach,bend,bay,...}</div>
</div>
<div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<div dir="ltr">* name=*</div>
</div>
<div> </div>
<p>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?</p>
<p>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?</p>
</div>
<div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p>On 2018-09-29 00:11, Graeme Fitzpatrick wrote:</p>
<blockquote style="padding:0 0.4em;border-left:#1010ff 2px solid;margin:0">
<div dir="ltr">
<div>
<div class="m_8033802330170536665m_5324516950538785472m_8718959558059010796m_3540628982885440581m_5160660584859841359gmail_signature" dir="ltr">
<div dir="ltr">
<div dir="ltr"> </div>
</div>
</div>
</div>
<div class="gmail_quote">
<div dir="ltr">On Sat, 29 Sep 2018 at 06:32, Colin Smale <<a href="mailto:colin.smale@xs4all.nl" target="_blank">colin.smale@xs4all.nl</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p><span style="font-size:10pt">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:</span></p>
<div dir="ltr">* there can be contiguous linear sections of a river which can have names</div>
<div dir="ltr">* they can be "straight" (for example "reaches") or "curved" (for example "bends")</div>
<div dir="ltr">* 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)</div>
<div dir="ltr">* they encompass the entire width of the river and are not just a 2D line</div>
</div>
</blockquote>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<div dir="ltr">This is pointing towards:</div>
<div dir="ltr">* a way along the centre line of the river (colinear with the main_stream lines?)</div>
<div dir="ltr">* waterway=river_section</div>
<div dir="ltr">* river_section={reach,bend,...}</div>
<div dir="ltr">* name=*</div>
</div>
</blockquote>
<div> </div>
<div>Liking your train of thought Colin.</div>
<div> </div>
<div>Just wondering, perhaps =river_feature?</div>
<div> </div>
<div>I'm not certain about "<span style="font-family:Verdana,Geneva,sans-serif;font-size:13.3333px">they encompass the entire width of the river" </span>though? Would that then exclude things like <em>"The Deep Hole"</em> & <em>"17 Mile Rocks"</em>, which are both named spots that I can point out on a map?</div>
<div> </div>
<div>Thanks</div>
<div> </div>
<div>Graeme </div>
</div>
</div>
<br>
<div class="m_8033802330170536665m_5324516950538785472m_8718959558059010796m_3540628982885440581m_5160660584859841359pre" style="margin:0;padding:0;font-family:monospace">_______________________________________________<br> Tagging mailing list<br> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noopener noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a></div>
</blockquote>
</div>
_______________________________________________<br> Tagging mailing list<br> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noopener noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a></blockquote>
</div>
</blockquote>
</div>
<br>
<div class="m_8033802330170536665m_5324516950538785472m_8718959558059010796m_3540628982885440581pre" style="margin:0;padding:0;font-family:monospace">_______________________________________________<br> Tagging mailing list<br> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noopener noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a></div>
</blockquote>
</div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>
</div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_8033802330170536665gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Dave Swarthout<br>Homer, Alaska<br>Chiang Mai, Thailand<br>Travel Blog at <a href="http://dswarthout.blogspot.com" target="_blank">http://dswarthout.blogspot.com</a></div></div>