[Tagging] Tagging a named river bend

Joseph Eisenberg joseph.eisenberg at gmail.com
Sun Sep 30 03:33:19 UTC 2018


I think this is a good solution for your situation; tagging bends and
reaches. It should work for other types of waterways too.

I assume in this example you will be splitting the way (waterway=river) at
the beginning and end of the bend? So there are no overlapping or duplicate
ways.
On Sun, Sep 30, 2018 at 11:28 AM Dave Swarthout <daveswarthout at gmail.com>
wrote:

> 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
> _______________________________________________
> 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/20180930/53b35f7a/attachment.html>


More information about the Tagging mailing list