[Tagging] Tagging a named river bend

[Yves]

Fine for me.
Yves 

Le 30 septembre 2018 06:19:21 GMT+02:00, Dave Swarthout <daveswarthout at gmail.com> a écrit :
>Correct. I will split the river way at either end of the bend and apply
>the section tags to that piece only. The river continues to have its
>own
>name tag while the bend has only the tags needed to identify it as a
>section with special characteristics, and also a name
>
>On Sun, Sep 30, 2018 at 10:33 AM Joseph Eisenberg <
>joseph.eisenberg at gmail.com> wrote:
>
>> 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
>>>
>>
>
>-- 
>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/c94bb27c/attachment.html>