Re: [Tagging] Tagging a named river bend

[Yves]

Fine for me.
Yves 

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

Re: [Tagging] Tagging a named river bend

[Dave Swarthout]

 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 
> 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 
 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
 

Re: [Tagging] 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 
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 
>>> 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

Re: [Tagging] Tagging a named river bend

[Dave Swarthout]

 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 
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 
>> 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

Re: [Tagging] 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 
wrote:

>
>
> sent from a phone
>
> > On 28. Sep 2018, at 02:39, Dave Swarthout 
> 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

Re: [Tagging] Tagging a named river bend

[Martin Koppenhoefer]

sent from a phone

> On 28. Sep 2018, at 02:39, Dave Swarthout  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

Re: [Tagging] 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 
mailto:joseph.eisenb...@gmail.com>> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

[Yves]

I think it would be hard to restrict natural=* to a node, but then, which way? 
Not a good idea IMHO.
Yves ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

[Joseph Eisenberg]

Oh, I see. I was thinking about use on a node only, where this would not be
a problem. Place=* tags are usually used on nodes, perhaps on areas
(controverially) but not on ways.

This reminds me of the problem with naming mountain ranges and ridges.
Right now we can name part of an individual ridge or a peak, but for
“mountain_range” you can only draw a node, or if you draw a way it will
duplicate the ways used for ridges.

Waterways allow use of a relation to hold the name and characteristics of
the whole river or canal, and shorter ways for parts of the river, but
there isn’t a way to yet to tag a particular point or short part of a
river. It’s like we have mountain_range relations and ways but no
natural=ridge or =peak or saddle tags

On Fri, Sep 28, 2018 at 10:07 AM Dave Swarthout 
wrote:

> @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 <
> joseph.eisenb...@gmail.com> wrote:
>
>> "waterway=" is usually used for features that have to do with linear
>> water features; values include dam, weir, lock, etc.
>>
>> Since the name of a bend would be most useful for boaters and kayakers
>> who are using a river as a waterway, I would recommend using
>> "waterway=bend".
>>
>> This could then also be used for a bend in a canal, for example.
>>
>> "place=*" doesn't say anything about if the feature is natural or a
>> settlement, and it isn't usually used for water features.
>>
>> 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
>>
>> On 9/28/18, Dave Swarthout  wrote:
>> > At first, the use of "section" seemed useful to consider. The tag
>> > "whitewater:section_name" has not been defined in the Wiki but might be
>> > adapted to this issue. However, the word "whitewater" would be
>> misleading
>> > IMO because this is a flat river that whitewater enthusiasts would not
>> seek
>> > out. Also, like place=locality it doesn't give any indication that this
>> is
>> > a bend or curve in a river.
>> >
>> > 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.
>> >
>> > See Taginfo: https://taginfo.openstreetmap.org/keys/place#values
>> >
>> > On Thu, Sep 27, 2018 at 11:38 PM Ture Pålsson 
>> wrote:
>> >
>> >> And again, with a link, this time! =)
>> >>
>> >>
>> >>
>> https://kso.etjanster.lantmateriet.se/?e=749899=7312843=9=default_background_noauth
>> >>
>> >>
>> >> 27 sep. 2018 kl. 18:36 skrev Ture Pålsson :
>> >>
>> >>
>> >> 27 sep. 2018 kl. 13:03 skrev Yves :
>> >>
>> >> Place=locality makes sense, I guess the name is also used for the area
>> >> close to the bend by extension.
>> >> Locality on a node is always troublesome, and I wonder if anybody uses
>> >> description=* to describe further the place, here this would be
>> something
>> >> like description=river bend.
>> >>
>> >>
>> >>
>> >> A simple place=locality gives no hint to a renderer that this is a
>> water
>> >> feature, and I can easily imagine a map style where one wants to do
>> >> something special with those, like using blue text.
>> >>
>> >> Look at this example from northern Sweden, where features in the river
>> >> (Bredselet, Trångforsen and Vidselet) have lent their names, but in
>> >> different grammatical form, the the nearby villages/hamlets of Bredsel,
>> >> Trångfors and Vidsel.
>> >>
>> >> (Follow there river and you'll see several other named rapids (-fors)
>> and
>> >> stretches of smooth water between them (-sel).
>> >>
>> >>
>> >> ___
>> >> 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
>> >
>>
>
>
> --
> 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 

Re: [Tagging] Tagging a named river bend

[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 
wrote:

> "waterway=" is usually used for features that have to do with linear
> water features; values include dam, weir, lock, etc.
>
> Since the name of a bend would be most useful for boaters and kayakers
> who are using a river as a waterway, I would recommend using
> "waterway=bend".
>
> This could then also be used for a bend in a canal, for example.
>
> "place=*" doesn't say anything about if the feature is natural or a
> settlement, and it isn't usually used for water features.
>
> 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
>
> On 9/28/18, Dave Swarthout  wrote:
> > At first, the use of "section" seemed useful to consider. The tag
> > "whitewater:section_name" has not been defined in the Wiki but might be
> > adapted to this issue. However, the word "whitewater" would be misleading
> > IMO because this is a flat river that whitewater enthusiasts would not
> seek
> > out. Also, like place=locality it doesn't give any indication that this
> is
> > a bend or curve in a river.
> >
> > 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.
> >
> > See Taginfo: https://taginfo.openstreetmap.org/keys/place#values
> >
> > On Thu, Sep 27, 2018 at 11:38 PM Ture Pålsson 
> wrote:
> >
> >> And again, with a link, this time! =)
> >>
> >>
> >>
> https://kso.etjanster.lantmateriet.se/?e=749899=7312843=9=default_background_noauth
> >>
> >>
> >> 27 sep. 2018 kl. 18:36 skrev Ture Pålsson :
> >>
> >>
> >> 27 sep. 2018 kl. 13:03 skrev Yves :
> >>
> >> Place=locality makes sense, I guess the name is also used for the area
> >> close to the bend by extension.
> >> Locality on a node is always troublesome, and I wonder if anybody uses
> >> description=* to describe further the place, here this would be
> something
> >> like description=river bend.
> >>
> >>
> >>
> >> A simple place=locality gives no hint to a renderer that this is a water
> >> feature, and I can easily imagine a map style where one wants to do
> >> something special with those, like using blue text.
> >>
> >> Look at this example from northern Sweden, where features in the river
> >> (Bredselet, Trångforsen and Vidselet) have lent their names, but in
> >> different grammatical form, the the nearby villages/hamlets of Bredsel,
> >> Trångfors and Vidsel.
> >>
> >> (Follow there river and you'll see several other named rapids (-fors)
> and
> >> stretches of smooth water between them (-sel).
> >>
> >>
> >> ___
> >> 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
> >
>


-- 
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

Re: [Tagging] Tagging a named river bend

[Joseph Eisenberg]

"waterway=" is usually used for features that have to do with linear
water features; values include dam, weir, lock, etc.

Since the name of a bend would be most useful for boaters and kayakers
who are using a river as a waterway, I would recommend using
"waterway=bend".

This could then also be used for a bend in a canal, for example.

"place=*" doesn't say anything about if the feature is natural or a
settlement, and it isn't usually used for water features.

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

On 9/28/18, Dave Swarthout  wrote:
> At first, the use of "section" seemed useful to consider. The tag
> "whitewater:section_name" has not been defined in the Wiki but might be
> adapted to this issue. However, the word "whitewater" would be misleading
> IMO because this is a flat river that whitewater enthusiasts would not seek
> out. Also, like place=locality it doesn't give any indication that this is
> a bend or curve in a river.
>
> 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.
>
> See Taginfo: https://taginfo.openstreetmap.org/keys/place#values
>
> On Thu, Sep 27, 2018 at 11:38 PM Ture Pålsson  wrote:
>
>> And again, with a link, this time! =)
>>
>>
>> https://kso.etjanster.lantmateriet.se/?e=749899=7312843=9=default_background_noauth
>>
>>
>> 27 sep. 2018 kl. 18:36 skrev Ture Pålsson :
>>
>>
>> 27 sep. 2018 kl. 13:03 skrev Yves :
>>
>> Place=locality makes sense, I guess the name is also used for the area
>> close to the bend by extension.
>> Locality on a node is always troublesome, and I wonder if anybody uses
>> description=* to describe further the place, here this would be something
>> like description=river bend.
>>
>>
>>
>> A simple place=locality gives no hint to a renderer that this is a water
>> feature, and I can easily imagine a map style where one wants to do
>> something special with those, like using blue text.
>>
>> Look at this example from northern Sweden, where features in the river
>> (Bredselet, Trångforsen and Vidselet) have lent their names, but in
>> different grammatical form, the the nearby villages/hamlets of Bredsel,
>> Trångfors and Vidsel.
>>
>> (Follow there river and you'll see several other named rapids (-fors) and
>> stretches of smooth water between them (-sel).
>>
>>
>> ___
>> 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

Re: [Tagging] Tagging a named river bend

[Dave Swarthout]

At first, the use of "section" seemed useful to consider. The tag
"whitewater:section_name" has not been defined in the Wiki but might be
adapted to this issue. However, the word "whitewater" would be misleading
IMO because this is a flat river that whitewater enthusiasts would not seek
out. Also, like place=locality it doesn't give any indication that this is
a bend or curve in a river.

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.

See Taginfo: https://taginfo.openstreetmap.org/keys/place#values

On Thu, Sep 27, 2018 at 11:38 PM Ture Pålsson  wrote:

> And again, with a link, this time! =)
>
>
> https://kso.etjanster.lantmateriet.se/?e=749899=7312843=9=default_background_noauth
>
>
> 27 sep. 2018 kl. 18:36 skrev Ture Pålsson :
>
>
> 27 sep. 2018 kl. 13:03 skrev Yves :
>
> Place=locality makes sense, I guess the name is also used for the area
> close to the bend by extension.
> Locality on a node is always troublesome, and I wonder if anybody uses
> description=* to describe further the place, here this would be something
> like description=river bend.
>
>
>
> A simple place=locality gives no hint to a renderer that this is a water
> feature, and I can easily imagine a map style where one wants to do
> something special with those, like using blue text.
>
> Look at this example from northern Sweden, where features in the river
> (Bredselet, Trångforsen and Vidselet) have lent their names, but in
> different grammatical form, the the nearby villages/hamlets of Bredsel,
> Trångfors and Vidsel.
>
> (Follow there river and you'll see several other named rapids (-fors) and
> stretches of smooth water between them (-sel).
>
>
> ___
> 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

Re: [Tagging] Tagging a named river bend

[Ture Pålsson]

And again, with a link, this time! =)

https://kso.etjanster.lantmateriet.se/?e=749899=7312843=9=default_background_noauth
 



> 27 sep. 2018 kl. 18:36 skrev Ture Pålsson :
> 
> 
>> 27 sep. 2018 kl. 13:03 skrev Yves :
>> 
>> Place=locality makes sense, I guess the name is also used for the area close 
>> to the bend by extension.
>> Locality on a node is always troublesome, and I wonder if anybody uses 
>> description=* to describe further the place, here this would be something 
>> like description=river bend. 
> 
> 
> A simple place=locality gives no hint to a renderer that this is a water 
> feature, and I can easily imagine a map style where one wants to do something 
> special with those, like using blue text.
> 
> Look at this example from northern Sweden, where features in the river 
> (Bredselet, Trångforsen and Vidselet) have lent their names, but in different 
> grammatical form, the the nearby villages/hamlets of Bredsel, Trångfors and 
> Vidsel.
> 
> (Follow there river and you'll see several other named rapids (-fors) and 
> stretches of smooth water between them (-sel).
> 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

[Ture Pålsson]

> 27 sep. 2018 kl. 13:03 skrev Yves :
> 
> Place=locality makes sense, I guess the name is also used for the area close 
> to the bend by extension.
> Locality on a node is always troublesome, and I wonder if anybody uses 
> description=* to describe further the place, here this would be something 
> like description=river bend. 


A simple place=locality gives no hint to a renderer that this is a water 
feature, and I can easily imagine a map style where one wants to do something 
special with those, like using blue text.

Look at this example from northern Sweden, where features in the river 
(Bredselet, Trångforsen and Vidselet) have lent their names, but in different 
grammatical form, the the nearby villages/hamlets of Bredsel, Trångfors and 
Vidsel.

(Follow there river and you'll see several other named rapids (-fors) and 
stretches of smooth water between them (-sel).


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

[Yves]

Section_name, is there not something like this in the whitewater tagging scheme?
Yep: 
https://wiki.openstreetmap.org/w/index.php?title=Key:whitewater:section_name=edit=1

And yes, this tagging scheme extend to brown/blue/green river sections.
Yves 

Le 27 septembre 2018 16:14:47 GMT+02:00, Martin Koppenhoefer 
 a écrit :
>
>
>sent from a phone
>
>> On 27. Sep 2018, at 15:57, Dave Swarthout 
>wrote:
>> 
>> This bend may or may not lend its name to a locality but it is
>primarily a feature of the river, not the name of a settled place.
>
>
>locality is explicitly for toponyms that don’t refer to settlements or
>their parts. I agree that a node is not nice, because we might want to
>tag sections of a river that are quite long, and a node doesn’t express
>this.
>
>Another idea would be to use additionally a subtag on the part, e.g.
>section_name=*
>
>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

Re: [Tagging] Tagging a named river bend

[Steve Doerr]

On 27/09/2018 15:17, Michael Patrick wrote:

*/a reach is just any length of a stream or river/*


*
*

It would seem odd to tag a bend as a reach, as the classic definition of 
a reach is 'A portion of a river, channel, or lake which lies between 
two bends or which can be seen in one view'.



--

Steve



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Tagging a named river bend

[Michael Patrick]

> It does not communicate the quality of "riverness" at all. This bend may
or may not lend its name to a locality but it is primarily a feature of the
river, not
the name of a settled place.

Generally, the term 'Reach' is most appropriate for subsections of flowing
water:
(From https://www.usgs.gov/faqs/what-a-reach )
What is a reach?

“Reach” can have *slightly different meanings*, depending on how it is used.

A reach is a section of a stream or river along which similar hydrologic
conditions exist, such as discharge, depth, area, and slope. It can also be
the length of a stream or river (with varying conditions) between two
stream gauges, or a length of river for which the characteristics are well
described by readings at a single stream gauge.

More generally, *a reach is just any length of a stream or river.* The term
is often used by hydrologists when they’re referring to a small section of
a river rather than its entire length from end to end.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

[Martin Koppenhoefer]

sent from a phone

> On 27. Sep 2018, at 15:57, Dave Swarthout  wrote:
> 
> This bend may or may not lend its name to a locality but it is primarily a 
> feature of the river, not the name of a settled place.


locality is explicitly for toponyms that don’t refer to settlements or their 
parts. I agree that a node is not nice, because we might want to tag sections 
of a river that are quite long, and a node doesn’t express this.

Another idea would be to use additionally a subtag on the part, e.g. 
section_name=*

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

[Dave Swarthout]

I would resist the use of the locality tag (also the other pro-node
arguments) even though it's an easy answer to my problem. It does not
communicate the quality of "riverness" at all. This bend may or may not
lend its name to a locality but it is primarily a feature of the river, not
the name of a settled place.

I like the suggestion of place=river_part because it works well with
existing waterway tags and would be searchable. I don't want to use the
waterway tag at all for this project; that "top-level" should be reserved
for the ways comprising a river, and is normally associated with the river
name. This is a separate but related part of a river. The scheme could even
be extended to include Colin's "reaches" or "holes" on the river Thames.

Hmmm



On Thu, Sep 27, 2018 at 8:25 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 27. Sep 2018, at 12:21, Joseph Eisenberg 
> wrote:
> >
> > To confirm, this name is for the section of river, not for the
> semi-circle of land inside of the bend?
>
>
> practically I would expect the name to extend to this piece of land as
> well (often).
>
>
> cheers,
> Martin



-- 
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

Re: [Tagging] Tagging a named river bend

[Martin Koppenhoefer]

sent from a phone

> On 27. Sep 2018, at 12:21, Joseph Eisenberg  
> wrote:
> 
> To confirm, this name is for the section of river, not for the semi-circle of 
> land inside of the bend?


practically I would expect the name to extend to this piece of land as well 
(often).


cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

[Martin Koppenhoefer]

sent from a phone

> On 27. Sep 2018, at 12:10, Warin <61sundow...@gmail.com> wrote:
> 
> I'd use
> place=locality 
> name=*


I don’t oppose this, but I feel it would be time to introduce an additional tag 
for localities that states which kind of toponym it is (where it comes from or 
what is refers to), e.g 
locality=*

Current usage of this tag is practically restricted to 2 values, townland and 
subtownland
https://taginfo.openstreetmap.org/keys/locality#values

we could introduce values like river_part or waterway_section (I’d prefer the 
former because the word river already gives a slight indication about the 
importance as opposed to ‘waterway’ which includes ditches).

the wiki discourages locality on a way though: 
https://wiki.openstreetmap.org/wiki/Tag%3Aplace%3Dlocality

Not sure if this should be changed or we should introduce a new tag like 
place=river_part (or similar) or waterway=section etc.

Cheers,
Martin___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

[Colin Smale]

I guess this can also apply to named straight bits as well? 

http://onthethames.net/reaches-river-thames/

On 2018-09-27 11:58, Dave Swarthout wrote:

> I'm working on adding islands and other features in the Tanana River in 
> Alaska. There are many named sloughs (side channels), islands and in some 
> areas curves or bends that have a name. In my example there is a large bend 
> in the river that has its own name, Harper Bend. I'm looking for a way to tag 
> that section so that the name is findable. It would be nice but not 
> imperative if that name would display on the OSM slippy map and incidentally, 
> on my GPSr. 
> 
> If I break the river at both ends of the curve, I could add the name to the 
> section between the breaks but that doesn't seem right because the river's 
> name isn't changing. Another much more complicated solution would be to break 
> the riverbank into sections and add a name to the one that encompasses the 
> bend. 
> 
> I don't know why I didn't ask here first but I raised this question on the 
> OSM Help forum and one answer was to use a node. But if one goes that way, I 
> reckon a new tag would be needed. So let's begin our discussion with that. 
> Given that it's important to me to describe our mapped objects as completely 
> as possible, I want a method to tag such a bend. 
> 
> Suggestions? Opinions? 
> Best, 
> Dave 
> -- 
> 
> 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

Re: [Tagging] Tagging a named river bend

[Yves]

Place=locality makes sense, I guess the name is also used for the area close to 
the bend by extension.
Locality on a node is always troublesome, and I wonder if anybody uses 
description=* to describe further the place, here this would be something like 
description=river bend. 

Le 27 septembre 2018 12:23:53 GMT+02:00, Peter Elderson  a 
écrit :
>+1
>If it's a well defined area, I would tag an area tagged place=* ,
>name=*
>If it's an island, I would tag place=island. If no regular place-value
>fits, then place=locality.
>If it's a normal thing, like when all bends in the river have a name,
>then
>I would probably enter a new place-value, e.g. river_bend.
>
>Op do 27 sep. 2018 om 12:12 schreef Warin <61sundow...@gmail.com>:
>
>> I'd use
>> place=locality
>> name=*
>>
>> Fits, renders and searchable. Put it on a node.
>>
>> On 27/09/18 19:58, Dave Swarthout wrote:
>>
>> I'm working on adding islands and other features in the Tanana River
>in
>> Alaska. There are many named sloughs (side channels), islands and in
>some
>> areas curves or bends that have a name. In my example there is a
>large bend
>> in the river that has its own name, Harper Bend. I'm looking for a
>way to
>> tag that section so that the name is findable. It would be nice but
>not
>> imperative if that name would display on the OSM slippy map and
>> incidentally, on my GPSr.
>>
>> If I break the river at both ends of the curve, I could add the name
>to
>> the section between the breaks but that doesn't seem right because
>the
>> river's name isn't changing. Another much more complicated solution
>would
>> be to break the riverbank into sections and add a name to the one
>that
>> encompasses the bend.
>>
>> I don't know why I didn't ask here first but I raised this question
>on the
>> OSM Help forum and one answer was to use a node. But if one goes that
>way,
>> I reckon a new tag would be needed. So let's begin our discussion
>with
>> that. Given that it's important to me to describe our mapped objects
>as
>> completely as possible, I want a method to tag such a bend.
>>
>> Suggestions? Opinions?
>> Best,
>> Dave
>> --
>> Dave Swarthout
>> Homer, Alaska
>> Chiang Mai, Thailand
>> Travel Blog at http://dswarthout.blogspot.com
>>
>>
>> ___
>> Tagging mailing
>listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>-- 
>Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

[Peter Elderson]

+1
If it's a well defined area, I would tag an area tagged place=* , name=*
If it's an island, I would tag place=island. If no regular place-value
fits, then place=locality.
If it's a normal thing, like when all bends in the river have a name, then
I would probably enter a new place-value, e.g. river_bend.

Op do 27 sep. 2018 om 12:12 schreef Warin <61sundow...@gmail.com>:

> I'd use
> place=locality
> name=*
>
> Fits, renders and searchable. Put it on a node.
>
> On 27/09/18 19:58, Dave Swarthout wrote:
>
> I'm working on adding islands and other features in the Tanana River in
> Alaska. There are many named sloughs (side channels), islands and in some
> areas curves or bends that have a name. In my example there is a large bend
> in the river that has its own name, Harper Bend. I'm looking for a way to
> tag that section so that the name is findable. It would be nice but not
> imperative if that name would display on the OSM slippy map and
> incidentally, on my GPSr.
>
> If I break the river at both ends of the curve, I could add the name to
> the section between the breaks but that doesn't seem right because the
> river's name isn't changing. Another much more complicated solution would
> be to break the riverbank into sections and add a name to the one that
> encompasses the bend.
>
> I don't know why I didn't ask here first but I raised this question on the
> OSM Help forum and one answer was to use a node. But if one goes that way,
> I reckon a new tag would be needed. So let's begin our discussion with
> that. Given that it's important to me to describe our mapped objects as
> completely as possible, I want a method to tag such a bend.
>
> Suggestions? Opinions?
> Best,
> Dave
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a named river bend

[Joseph Eisenberg]

I agree that a node is best, because it is  debatable where a river bend
starts and ends, but it is easy to put a node at the center.

To confirm, this name is for the section of river, not for the semi-circle
of land inside of the bend?

I agree that a separate tag is needed, as you said, because this is not the
name of a river. It’s analogous to a bay in a lake or sea.

Did you try searching taginfo? Has anyone been using waterway=bend or
natural=bend, or something similar?

-Joseph

On Thu, Sep 27, 2018 at 7:00 PM Dave Swarthout 
wrote:

> I'm working on adding islands and other features in the Tanana River in
> Alaska. There are many named sloughs (side channels), islands and in some
> areas curves or bends that have a name. In my example there is a large bend
> in the river that has its own name, Harper Bend. I'm looking for a way to
> tag that section so that the name is findable. It would be nice but not
> imperative if that name would display on the OSM slippy map and
> incidentally, on my GPSr.
>
> If I break the river at both ends of the curve, I could add the name to
> the section between the breaks but that doesn't seem right because the
> river's name isn't changing. Another much more complicated solution would
> be to break the riverbank into sections and add a name to the one that
> encompasses the bend.
>
> I don't know why I didn't ask here first but I raised this question on the
> OSM Help forum and one answer was to use a node. But if one goes that way,
> I reckon a new tag would be needed. So let's begin our discussion with
> that. Given that it's important to me to describe our mapped objects as
> completely as possible, I want a method to tag such a bend.
>
> Suggestions? Opinions?
> Best,
> Dave
>
> --
> 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

Re: [Tagging] Tagging a named river bend

[Warin]

I'd use
place=locality
name=*

Fits, renders and searchable. Put it on a node.

On 27/09/18 19:58, Dave Swarthout wrote:


I'm working on adding islands and other features in the Tanana River 
in Alaska. There are many named sloughs (side channels), islands and 
in some areas curves or bends that have a name. In my example there is 
a large bend in the river that has its own name, Harper Bend. I'm 
looking for a way to tag that section so that the name is findable. It 
would be nice but not imperative if that name would display on the OSM 
slippy map and incidentally, on my GPSr.


If I break the river at both ends of the curve, I could add the name 
to the section between the breaks but that doesn't seem right because 
the river's name isn't changing. Another much more complicated 
solution would be to break the riverbank into sections and add a name 
to the one that encompasses the bend.


I don't know why I didn't ask here first but I raised this question on 
the OSM Help forum and one answer was to use a node. But if one goes 
that way, I reckon a new tag would be needed. So let's begin our 
discussion with that. Given that it's important to me to describe our 
mapped objects as completely as possible, I want a method to tag such 
a bend.


Suggestions? Opinions?

Best,
Dave
--
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

[Tagging] Tagging a named river bend

[Dave Swarthout]

I'm working on adding islands and other features in the Tanana River in
Alaska. There are many named sloughs (side channels), islands and in some
areas curves or bends that have a name. In my example there is a large bend
in the river that has its own name, Harper Bend. I'm looking for a way to
tag that section so that the name is findable. It would be nice but not
imperative if that name would display on the OSM slippy map and
incidentally, on my GPSr.

If I break the river at both ends of the curve, I could add the name to the
section between the breaks but that doesn't seem right because the river's
name isn't changing. Another much more complicated solution would be to
break the riverbank into sections and add a name to the one that
encompasses the bend.

I don't know why I didn't ask here first but I raised this question on the
OSM Help forum and one answer was to use a node. But if one goes that way,
I reckon a new tag would be needed. So let's begin our discussion with
that. Given that it's important to me to describe our mapped objects as
completely as possible, I want a method to tag such a bend.

Suggestions? Opinions?
Best,
Dave
-- 
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