Re: Tagging a named river bend

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Tagging a named river bend

Tobias Wrede
Am 28.09.2018 um 03:06 schrieb Dave Swarthout:
@Joseph - I wanted to avoid using that particular top-level tag, waterway, because there would be no simple way to add a name different from that of the waterway=river itself. Unless we invent a new tag something like name:bend=Harper Bend.

The key "natural" is so weighted with controversy already, I'd prefer not to use that one either. But I'm not opposed if we can all agree on its use here.

On Fri, Sep 28, 2018 at 7:54 AM Joseph Eisenberg <[hidden email]> wrote:
[...]
Another option would be natural=bend or natural=river_bend, because
natural=* is used for all sorts of geographic features in the natural
landscape, including water features like bays, straights, etc.

Joseph

Natural=* might be controversial. But in my opinion a river bend is very similar to a bay, strait, fjord etc. These are all parts of a bigger water body with diffuse boarders. I'd like to keep in line with those established taggings. It could be natural=river_section, which could serve for bends, straights, widenings, narrowings, pits in the river bed, etc., or more specific natural=river_bend.

Having that said, I admit that would we not already have those key/value pairs I might rather go for something better indicating we are talking about something water related.

Tobi


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging a named river bend

dieterdreist


sent from a phone

> On 28. Sep 2018, at 02:39, Dave Swarthout <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging a named river bend

Joseph Eisenberg
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 <[hidden email]> wrote:


sent from a phone

> On 28. Sep 2018, at 02:39, Dave Swarthout <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging a named river bend

AlaskaDave
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 <[hidden email]> 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 <[hidden email]> wrote:


sent from a phone

> On 28. Sep 2018, at 02:39, Dave Swarthout <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging a named river bend

Joseph Eisenberg
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


sent from a phone

> On 28. Sep 2018, at 02:39, Dave Swarthout <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging a named river bend

AlaskaDave
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


sent from a phone

> On 28. Sep 2018, at 02:39, Dave Swarthout <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Tagging a named river bend

Yves-2
Fine for me.
Yves

Le 30 septembre 2018 06:19:21 GMT+02:00, Dave Swarthout <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


sent from a phone

> On 28. Sep 2018, at 02:39, Dave Swarthout <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging