Fine for me. Yves
Le 30 septembre 2018 06:19:21 GMT+02:00, Dave Swarthout <daveswarth...@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.eisenb...@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 ><daveswarth...@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.eisenb...@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 < >>>> dieterdre...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> sent from a phone >>>>> >>>>> > On 28. Sep 2018, at 02:39, Dave Swarthout ><daveswarth...@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@openstreetmap.org >>>>> https://lists.openstreetmap.org/listinfo/tagging >>>>> >>>> _______________________________________________ >>>> Tagging mailing list >>>> Tagging@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@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@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging