[Tagging] Tagging a named river bend

[Dave Swarthout]

 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?

This example uses the colon ":" as a separator for different parts of the
keys rather than mixing it with the underscore character "_".

> waterway=river
> name=Tanana River
> waterway:section=bend
> waterway:section:name=Harper Bend

Pros and cons (subject to the limitations I mentioned)?

On Sun, Sep 30, 2018 at 6:09 AM Joseph Eisenberg <joseph.eisenberg at gmail.com>
wrote:

> Re: "I would not discard the idea of using some kind of relation for this
> (type=route is not suitable, or is it?). It is the most flexible way to tag
> as it allows for overlapping entities and avoids duplication of ways."
>
> In theory, it would be great to be able to build up a long river from many
> nested relations, but it doesn't seem to work now.
>
> Imagine a long river that passes through different language regions, and
> therefore has a different name near the headwaters, in the middle, and near
> the sea. Each short bend, reach, or rapid (in a whitewater river) would be
> a way, perhaps 1/2 to 2km long. Then each named section of the river would
> be made up of several of these ways. And the three long parts of the
> waterway with a different name*(eg name:de= then name:fr= then name:nl=,
> from mountains to sea) would be a relation made up of the shorter relations.
>
> Unfortunately, because "super"-relations are not handled well in the
> editors or any applications, this would be hard to maintain and hard for
> database users. I actually tried doing this for a river in New Guinea that
> changes names between mountains and lowlands, by making a "super"-relation
> that continued a couple of sub-relations, but JOSM complains and it doesn't
> seem to render.
>
> If we ever manage to add "area" as a database primitive, we should
> consider adding "multipolygon" as an area made up of constituent polygons
> and ways, and "linestring" or something, as a longer way made up of shorter
> ways, if such a thing is possible.
>
> (When I used to be able to edit roads on Google Maps, the API seemed to be
> able to recognize that a short segment of a street was part of the longer
> street, and suggested editing the whole longer way (or relation?) when I
> would select the short segment. )
>
> -Joseph
>
> On Sat, Sep 29, 2018 at 10:55 PM Martin Koppenhoefer <
> dieterdreist at gmail.com> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 28. Sep 2018, at 02:39, Dave Swarthout <daveswarthout at gmail.com>
>> wrote:
>> >
>> > I keep coming back to Martin's place=river_bend. Adding a name=Harper
>> Bend along with that tag would solve the problem in a straightforward
>> manner, would not be confused with the specialized whitewater tagging
>> schemes and would be relatively easy to implement. A look at Taginfo tells
>> me that the "place"  key has been misused quite a bit but I think
>> place=river_bend would be a logical and easily understood new use of the
>> key.
>>
>>
>> this works best if you want to focus on the fact it is a bend. If we want
>> something more generic like “section” that could maybe even be applied to
>> named sections of other linear features like city walls / walls, etc.
>>
>> I would not discard the idea of using some kind of relation for this
>> (type=route is not suitable, or is it?). It is the most flexible way to tag
>> as it allows for overlapping entities and avoids duplication of ways. If
>> overlapping is not required, an additional property like xxx_name does it
>> (according to what is xxx, an additional place or waterway or other
>> classifying tag would be helpful).
>>
>>
>> Cheers,
>> Martin
>> _______________________________________________
>> 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
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180930/7e13faf6/attachment.html>