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 >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
