Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
And while we're discussing here, Mateusz is already on a rampage to
change wiki pages, write patches etc. Thus buldozzing his opinion,
ignoring others. Showing "community building" behaviour.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Martin Koppenhoefer


sent from a phone

> On 16. Dec 2020, at 17:52, Joseph Eisenberg  
> wrote:
> 
> You still have to distinguish marine water (outside of the natural=coastline) 
> from inland waters, and distinguishing rivers from lakes is very important 
> for proper rendering of many maps.


and it seems landuse=reservoir is used for sewage as well:
https://taginfo.openstreetmap.org/tags/reservoir_type=sewage

is this appropriate for natural=water?

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Graeme Fitzpatrick
On Thu, 17 Dec 2020 at 12:43, Joseph Eisenberg 
wrote:

> That example certainly looks like a landuse=basin or water=basin feature
> with basin=retention
>

Maybe? But there's an awful lot of them tagged as reservoirs!

Thanks

Graeme

>
> On Wed, Dec 16, 2020 at 6:23 PM Graeme Fitzpatrick 
> wrote:
>
>> In an Australian context, the most common are known as Turkey's Nest
>> dams, because they're mounded up above the ground eg
>>
>> https://c8.alamy.com/comp/A6T7R0/turkey-nest-dam-on-outback-cattle-station-queensland-australia-A6T7R0.jpg
>>
>> For a full explanation:
>> https://www.agric.wa.gov.au/water-management/excavated-tanks-farm-dams
>>
>> Thanks
>>
>> Graeme
>>
>>
>> On Thu, 17 Dec 2020 at 11:53, Joseph Guillaume 
>> wrote:
>>
>>> That Wikipedia page is right.
>>> The artificial grading mostly involves creating an (earthen) dam wall
>>> (which is often also mapped), and the purpose is generally retention of
>>> water rather than infiltration or detention, which is why the distinction
>>> between reservoir and basin isn't clear cut to me.
>>>
>>> I'm having trouble thinking of it as a basin, but it does seem like this
>>> is the intended tag. Thanks!
>>>
>>>
>>>
>>> On Thu, 17 Dec 2020, 12:29 pm Joseph Eisenberg, <
>>> joseph.eisenb...@gmail.com> wrote:
>>>
 What is a farm dam in this context? We don't have that term in American
 English.

 Is this perhaps an example of landuse=basin (or if you prefer
 water=basin) with basin=detention or basin=infiltration?

 https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbasin

 https://en.wikipedia.org/wiki/Dam_(agricultural_reservoir)

 -- Joseph Eisenberg

 On Wed, Dec 16, 2020 at 1:29 PM Joseph Guillaume <
 josephguilla...@gmail.com> wrote:

> This discussion has convinced me not to use landuse=reservoir.
>
> It sounds like the only benefit is its historical use, whereas I've
> personally seen benefits of the natural=water approach.
>
> I've mapped quite a number of farm dams as natural=water without being
> sure what subtag to use.
> I now think that's because there isn't an appropriate subtag. I
> definitely don't want to tag it as a pond. While a farm dam is 
> structurally
> and functionally a reservoir, there are clear differences with large
> reservoirs.
>
> Already now, farm dams tend to be mapped more prominently than I'd
> expect. The dominant feature of these grazing landscapes is fencing, and
> I'd therefore expect farm dams to appear on a similar scale to fences.
> water=reservoir and landuse=reservoir wouldn't do that.
>
> One of the things I love about OSM is the ability to map
> incrementally, which by definition results in incomplete, lower quality
> maps that are constantly improving. If the priority was a high quality 
> map,
> we'd map systematically (like Missing maps, but for everything that will
> appear on a render) and not release an area until it was done. I wouldn't
> be mapping.
>
>
> On Thu, 17 Dec 2020, 1:26 am Tomas Straupis, 
> wrote:
>
>> 2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
>> >
>> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
>> > (just added)
>>
>>   Thank you. Maybe it is better to discuss here before adding to wiki?
>>   My arguments on the points you've added:
>>
>>   1. Regarding benefit of having a combining level/tag natural=water.
>> If today you would query all data with natural=water - you will get
>> not only lakes and reservoirs grouped, but also riverbank polygons
>> (totally different beast) and micro elements like water=pond. This
>> could only be partly useful in the largest scale maps and only if you
>> make very simple maps and for some reason use the same symbolisation
>> for such different water classes. For example ponds usually have less
>> complex and less prominent symbolisation because of their size and
>> importance. Riverbanks would not need polygon labelling, but rather
>> use river (central) line for label placement. Most of GIS/Cartography
>> work goes in middle/small scales and it will be impossible to use only
>> natural=water there, you would have to add "and water not in
>> ('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
>> makes it of the same complexity from coding perspective as original
>> water scheme.
>>
>>   2. Very important disadvantage of water=reservoir from
>> cartographic/gis perspective: it allows mappers to NOT differentiate
>> between natural lakes and man made reservoirs. If first point
>> describes how different classes are USED, this second point is about
>> how these classes are CAPTURED.
>>
>>   Did I miss anything?
>>
>> ___
>> Tagging mailing list

Re: [Tagging] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread stevea
I'm not sure how long it is, but California's Highway 1 along the Big Sur coast 
(a fairly well known, well loved road) has some equivalently lengthy (or 
longer) winding road signs I've seen.  If anyone cares to Mapillary-sniff, I 
recall one near Carmel Highlands (near the "pink hotel?") and another further 
south, near McWay Falls or is it more near JFBSP?  Esalen?  Definitely seen 
some around there).  Northbound you might have to look around Cambria, I don't 
often approach from that side (northbound).  Long, sinuous roads do happen and 
are sometimes even signed.  I think that despite how famous this drive is 
(about as well-driven as Yosemite National Park in summer), you don't want to 
be in a 12-meter motorhome on this road and not know what the next 200 
kilometers are going to be like (windy and very few places to pull over or park 
such a behemoth). Still, such "big traffic" (giant Recreational Vehicles) do 
make this trek.  Such a sign might make someone think twice and I think that's 
part of the reason Caltrans erects them.  And nobody likes getting stuck behind 
a slow, giant RV.

> On Dec 16, 2020, at 6:15 PM, Graeme Fitzpatrick  wrote:
> On Thu, 17 Dec 2020 at 11:24, Brian M. Sperlongano  
> wrote:

> Thanks for the comments!  For the specific linked case (winding road for 
> 74(!) miles), it seems that is already covered in the proposal - 
> hazard=curves and its sub-tags cover this, and if it truly is 74 consecutive 
> miles, that I would think it's just fine to tag 74 miles worth of ways in 
> this way.
> 
> & we'll have to do the same for this! :-)
> 
> https://c8.alamy.com/comp/BPN0FY/warning-sign-on-the-eyre-highway-across-the-nullarbor-plain-western-BPN0FY.jpg

And the Nullarbor Plain (love that name) I think also famously has the longest 
straight stretch of railway on Earth.  I'd tend to say "railroad," US English 
being my mother tongue, "railroad" for "railway" being a US English dialect 
marker.  Like holding up three fingers in a certain way.  Or Ex-Wye-Zed vs. 
Ex-Wye-Zee.  It's a big world.  Lots of long, straight roads, lots of long, 
windy roads.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Joseph Eisenberg
That example certainly looks like a landuse=basin or water=basin feature
with basin=retention

On Wed, Dec 16, 2020 at 6:23 PM Graeme Fitzpatrick 
wrote:

> In an Australian context, the most common are known as Turkey's Nest dams,
> because they're mounded up above the ground eg
>
> https://c8.alamy.com/comp/A6T7R0/turkey-nest-dam-on-outback-cattle-station-queensland-australia-A6T7R0.jpg
>
> For a full explanation:
> https://www.agric.wa.gov.au/water-management/excavated-tanks-farm-dams
>
> Thanks
>
> Graeme
>
>
> On Thu, 17 Dec 2020 at 11:53, Joseph Guillaume 
> wrote:
>
>> That Wikipedia page is right.
>> The artificial grading mostly involves creating an (earthen) dam wall
>> (which is often also mapped), and the purpose is generally retention of
>> water rather than infiltration or detention, which is why the distinction
>> between reservoir and basin isn't clear cut to me.
>>
>> I'm having trouble thinking of it as a basin, but it does seem like this
>> is the intended tag. Thanks!
>>
>>
>>
>> On Thu, 17 Dec 2020, 12:29 pm Joseph Eisenberg, <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> What is a farm dam in this context? We don't have that term in American
>>> English.
>>>
>>> Is this perhaps an example of landuse=basin (or if you prefer
>>> water=basin) with basin=detention or basin=infiltration?
>>>
>>> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbasin
>>>
>>> https://en.wikipedia.org/wiki/Dam_(agricultural_reservoir)
>>>
>>> -- Joseph Eisenberg
>>>
>>> On Wed, Dec 16, 2020 at 1:29 PM Joseph Guillaume <
>>> josephguilla...@gmail.com> wrote:
>>>
 This discussion has convinced me not to use landuse=reservoir.

 It sounds like the only benefit is its historical use, whereas I've
 personally seen benefits of the natural=water approach.

 I've mapped quite a number of farm dams as natural=water without being
 sure what subtag to use.
 I now think that's because there isn't an appropriate subtag. I
 definitely don't want to tag it as a pond. While a farm dam is structurally
 and functionally a reservoir, there are clear differences with large
 reservoirs.

 Already now, farm dams tend to be mapped more prominently than I'd
 expect. The dominant feature of these grazing landscapes is fencing, and
 I'd therefore expect farm dams to appear on a similar scale to fences.
 water=reservoir and landuse=reservoir wouldn't do that.

 One of the things I love about OSM is the ability to map incrementally,
 which by definition results in incomplete, lower quality maps that are
 constantly improving. If the priority was a high quality map, we'd map
 systematically (like Missing maps, but for everything that will appear on a
 render) and not release an area until it was done. I wouldn't be mapping.


 On Thu, 17 Dec 2020, 1:26 am Tomas Straupis, 
 wrote:

> 2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
> >
> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
> > (just added)
>
>   Thank you. Maybe it is better to discuss here before adding to wiki?
>   My arguments on the points you've added:
>
>   1. Regarding benefit of having a combining level/tag natural=water.
> If today you would query all data with natural=water - you will get
> not only lakes and reservoirs grouped, but also riverbank polygons
> (totally different beast) and micro elements like water=pond. This
> could only be partly useful in the largest scale maps and only if you
> make very simple maps and for some reason use the same symbolisation
> for such different water classes. For example ponds usually have less
> complex and less prominent symbolisation because of their size and
> importance. Riverbanks would not need polygon labelling, but rather
> use river (central) line for label placement. Most of GIS/Cartography
> work goes in middle/small scales and it will be impossible to use only
> natural=water there, you would have to add "and water not in
> ('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
> makes it of the same complexity from coding perspective as original
> water scheme.
>
>   2. Very important disadvantage of water=reservoir from
> cartographic/gis perspective: it allows mappers to NOT differentiate
> between natural lakes and man made reservoirs. If first point
> describes how different classes are USED, this second point is about
> how these classes are CAPTURED.
>
>   Did I miss anything?
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Graeme Fitzpatrick
I should have added ...

So really, they're not "natural" in any way (except for the water in them!,
& even that is frequently pumped in).

Thanks

Graeme


On Thu, 17 Dec 2020 at 12:20, Graeme Fitzpatrick 
wrote:

> In an Australian context, the most common are known as Turkey's Nest dams,
> because they're mounded up above the ground eg
>
> https://c8.alamy.com/comp/A6T7R0/turkey-nest-dam-on-outback-cattle-station-queensland-australia-A6T7R0.jpg
>
> For a full explanation:
> https://www.agric.wa.gov.au/water-management/excavated-tanks-farm-dams
>
> Thanks
>
> Graeme
>
>
> On Thu, 17 Dec 2020 at 11:53, Joseph Guillaume 
> wrote:
>
>> That Wikipedia page is right.
>> The artificial grading mostly involves creating an (earthen) dam wall
>> (which is often also mapped), and the purpose is generally retention of
>> water rather than infiltration or detention, which is why the distinction
>> between reservoir and basin isn't clear cut to me.
>>
>> I'm having trouble thinking of it as a basin, but it does seem like this
>> is the intended tag. Thanks!
>>
>>
>>
>> On Thu, 17 Dec 2020, 12:29 pm Joseph Eisenberg, <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> What is a farm dam in this context? We don't have that term in American
>>> English.
>>>
>>> Is this perhaps an example of landuse=basin (or if you prefer
>>> water=basin) with basin=detention or basin=infiltration?
>>>
>>> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbasin
>>>
>>> https://en.wikipedia.org/wiki/Dam_(agricultural_reservoir)
>>>
>>> -- Joseph Eisenberg
>>>
>>> On Wed, Dec 16, 2020 at 1:29 PM Joseph Guillaume <
>>> josephguilla...@gmail.com> wrote:
>>>
 This discussion has convinced me not to use landuse=reservoir.

 It sounds like the only benefit is its historical use, whereas I've
 personally seen benefits of the natural=water approach.

 I've mapped quite a number of farm dams as natural=water without being
 sure what subtag to use.
 I now think that's because there isn't an appropriate subtag. I
 definitely don't want to tag it as a pond. While a farm dam is structurally
 and functionally a reservoir, there are clear differences with large
 reservoirs.

 Already now, farm dams tend to be mapped more prominently than I'd
 expect. The dominant feature of these grazing landscapes is fencing, and
 I'd therefore expect farm dams to appear on a similar scale to fences.
 water=reservoir and landuse=reservoir wouldn't do that.

 One of the things I love about OSM is the ability to map incrementally,
 which by definition results in incomplete, lower quality maps that are
 constantly improving. If the priority was a high quality map, we'd map
 systematically (like Missing maps, but for everything that will appear on a
 render) and not release an area until it was done. I wouldn't be mapping.


 On Thu, 17 Dec 2020, 1:26 am Tomas Straupis, 
 wrote:

> 2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
> >
> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
> > (just added)
>
>   Thank you. Maybe it is better to discuss here before adding to wiki?
>   My arguments on the points you've added:
>
>   1. Regarding benefit of having a combining level/tag natural=water.
> If today you would query all data with natural=water - you will get
> not only lakes and reservoirs grouped, but also riverbank polygons
> (totally different beast) and micro elements like water=pond. This
> could only be partly useful in the largest scale maps and only if you
> make very simple maps and for some reason use the same symbolisation
> for such different water classes. For example ponds usually have less
> complex and less prominent symbolisation because of their size and
> importance. Riverbanks would not need polygon labelling, but rather
> use river (central) line for label placement. Most of GIS/Cartography
> work goes in middle/small scales and it will be impossible to use only
> natural=water there, you would have to add "and water not in
> ('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
> makes it of the same complexity from coding perspective as original
> water scheme.
>
>   2. Very important disadvantage of water=reservoir from
> cartographic/gis perspective: it allows mappers to NOT differentiate
> between natural lakes and man made reservoirs. If first point
> describes how different classes are USED, this second point is about
> how these classes are CAPTURED.
>
>   Did I miss anything?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Graeme Fitzpatrick
In an Australian context, the most common are known as Turkey's Nest dams,
because they're mounded up above the ground eg
https://c8.alamy.com/comp/A6T7R0/turkey-nest-dam-on-outback-cattle-station-queensland-australia-A6T7R0.jpg

For a full explanation:
https://www.agric.wa.gov.au/water-management/excavated-tanks-farm-dams

Thanks

Graeme


On Thu, 17 Dec 2020 at 11:53, Joseph Guillaume 
wrote:

> That Wikipedia page is right.
> The artificial grading mostly involves creating an (earthen) dam wall
> (which is often also mapped), and the purpose is generally retention of
> water rather than infiltration or detention, which is why the distinction
> between reservoir and basin isn't clear cut to me.
>
> I'm having trouble thinking of it as a basin, but it does seem like this
> is the intended tag. Thanks!
>
>
>
> On Thu, 17 Dec 2020, 12:29 pm Joseph Eisenberg, <
> joseph.eisenb...@gmail.com> wrote:
>
>> What is a farm dam in this context? We don't have that term in American
>> English.
>>
>> Is this perhaps an example of landuse=basin (or if you prefer
>> water=basin) with basin=detention or basin=infiltration?
>>
>> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbasin
>>
>> https://en.wikipedia.org/wiki/Dam_(agricultural_reservoir)
>>
>> -- Joseph Eisenberg
>>
>> On Wed, Dec 16, 2020 at 1:29 PM Joseph Guillaume <
>> josephguilla...@gmail.com> wrote:
>>
>>> This discussion has convinced me not to use landuse=reservoir.
>>>
>>> It sounds like the only benefit is its historical use, whereas I've
>>> personally seen benefits of the natural=water approach.
>>>
>>> I've mapped quite a number of farm dams as natural=water without being
>>> sure what subtag to use.
>>> I now think that's because there isn't an appropriate subtag. I
>>> definitely don't want to tag it as a pond. While a farm dam is structurally
>>> and functionally a reservoir, there are clear differences with large
>>> reservoirs.
>>>
>>> Already now, farm dams tend to be mapped more prominently than I'd
>>> expect. The dominant feature of these grazing landscapes is fencing, and
>>> I'd therefore expect farm dams to appear on a similar scale to fences.
>>> water=reservoir and landuse=reservoir wouldn't do that.
>>>
>>> One of the things I love about OSM is the ability to map incrementally,
>>> which by definition results in incomplete, lower quality maps that are
>>> constantly improving. If the priority was a high quality map, we'd map
>>> systematically (like Missing maps, but for everything that will appear on a
>>> render) and not release an area until it was done. I wouldn't be mapping.
>>>
>>>
>>> On Thu, 17 Dec 2020, 1:26 am Tomas Straupis, 
>>> wrote:
>>>
 2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
 >
 https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
 > (just added)

   Thank you. Maybe it is better to discuss here before adding to wiki?
   My arguments on the points you've added:

   1. Regarding benefit of having a combining level/tag natural=water.
 If today you would query all data with natural=water - you will get
 not only lakes and reservoirs grouped, but also riverbank polygons
 (totally different beast) and micro elements like water=pond. This
 could only be partly useful in the largest scale maps and only if you
 make very simple maps and for some reason use the same symbolisation
 for such different water classes. For example ponds usually have less
 complex and less prominent symbolisation because of their size and
 importance. Riverbanks would not need polygon labelling, but rather
 use river (central) line for label placement. Most of GIS/Cartography
 work goes in middle/small scales and it will be impossible to use only
 natural=water there, you would have to add "and water not in
 ('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
 makes it of the same complexity from coding perspective as original
 water scheme.

   2. Very important disadvantage of water=reservoir from
 cartographic/gis perspective: it allows mappers to NOT differentiate
 between natural lakes and man made reservoirs. If first point
 describes how different classes are USED, this second point is about
 how these classes are CAPTURED.

   Did I miss anything?

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

Re: [Tagging] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread Graeme Fitzpatrick
On Thu, 17 Dec 2020 at 11:24, Brian M. Sperlongano 
wrote:

>
>
> Thanks for the comments!  For the specific linked case (winding road for
> 74(!) miles), it seems that is already covered in the proposal -
> hazard=curves and its sub-tags cover this, and if it truly is 74
> consecutive miles, that I would think it's just fine to tag 74 miles worth
> of ways in this way.
>

& we'll have to do the same for this! :-)

https://c8.alamy.com/comp/BPN0FY/warning-sign-on-the-eyre-highway-across-the-nullarbor-plain-western-BPN0FY.jpg

Thanks

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Joseph Guillaume
That Wikipedia page is right.
The artificial grading mostly involves creating an (earthen) dam wall
(which is often also mapped), and the purpose is generally retention of
water rather than infiltration or detention, which is why the distinction
between reservoir and basin isn't clear cut to me.

I'm having trouble thinking of it as a basin, but it does seem like this is
the intended tag. Thanks!



On Thu, 17 Dec 2020, 12:29 pm Joseph Eisenberg, 
wrote:

> What is a farm dam in this context? We don't have that term in American
> English.
>
> Is this perhaps an example of landuse=basin (or if you prefer water=basin)
> with basin=detention or basin=infiltration?
>
> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbasin
>
> https://en.wikipedia.org/wiki/Dam_(agricultural_reservoir)
>
> -- Joseph Eisenberg
>
> On Wed, Dec 16, 2020 at 1:29 PM Joseph Guillaume <
> josephguilla...@gmail.com> wrote:
>
>> This discussion has convinced me not to use landuse=reservoir.
>>
>> It sounds like the only benefit is its historical use, whereas I've
>> personally seen benefits of the natural=water approach.
>>
>> I've mapped quite a number of farm dams as natural=water without being
>> sure what subtag to use.
>> I now think that's because there isn't an appropriate subtag. I
>> definitely don't want to tag it as a pond. While a farm dam is structurally
>> and functionally a reservoir, there are clear differences with large
>> reservoirs.
>>
>> Already now, farm dams tend to be mapped more prominently than I'd
>> expect. The dominant feature of these grazing landscapes is fencing, and
>> I'd therefore expect farm dams to appear on a similar scale to fences.
>> water=reservoir and landuse=reservoir wouldn't do that.
>>
>> One of the things I love about OSM is the ability to map incrementally,
>> which by definition results in incomplete, lower quality maps that are
>> constantly improving. If the priority was a high quality map, we'd map
>> systematically (like Missing maps, but for everything that will appear on a
>> render) and not release an area until it was done. I wouldn't be mapping.
>>
>>
>> On Thu, 17 Dec 2020, 1:26 am Tomas Straupis, 
>> wrote:
>>
>>> 2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
>>> >
>>> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
>>> > (just added)
>>>
>>>   Thank you. Maybe it is better to discuss here before adding to wiki?
>>>   My arguments on the points you've added:
>>>
>>>   1. Regarding benefit of having a combining level/tag natural=water.
>>> If today you would query all data with natural=water - you will get
>>> not only lakes and reservoirs grouped, but also riverbank polygons
>>> (totally different beast) and micro elements like water=pond. This
>>> could only be partly useful in the largest scale maps and only if you
>>> make very simple maps and for some reason use the same symbolisation
>>> for such different water classes. For example ponds usually have less
>>> complex and less prominent symbolisation because of their size and
>>> importance. Riverbanks would not need polygon labelling, but rather
>>> use river (central) line for label placement. Most of GIS/Cartography
>>> work goes in middle/small scales and it will be impossible to use only
>>> natural=water there, you would have to add "and water not in
>>> ('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
>>> makes it of the same complexity from coding perspective as original
>>> water scheme.
>>>
>>>   2. Very important disadvantage of water=reservoir from
>>> cartographic/gis perspective: it allows mappers to NOT differentiate
>>> between natural lakes and man made reservoirs. If first point
>>> describes how different classes are USED, this second point is about
>>> how these classes are CAPTURED.
>>>
>>>   Did I miss anything?
>>>
>>> ___
>>> 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 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Joseph Eisenberg
What is a farm dam in this context? We don't have that term in American
English.

Is this perhaps an example of landuse=basin (or if you prefer water=basin)
with basin=detention or basin=infiltration?

https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbasin

https://en.wikipedia.org/wiki/Dam_(agricultural_reservoir)

-- Joseph Eisenberg

On Wed, Dec 16, 2020 at 1:29 PM Joseph Guillaume 
wrote:

> This discussion has convinced me not to use landuse=reservoir.
>
> It sounds like the only benefit is its historical use, whereas I've
> personally seen benefits of the natural=water approach.
>
> I've mapped quite a number of farm dams as natural=water without being
> sure what subtag to use.
> I now think that's because there isn't an appropriate subtag. I definitely
> don't want to tag it as a pond. While a farm dam is structurally and
> functionally a reservoir, there are clear differences with large reservoirs.
>
> Already now, farm dams tend to be mapped more prominently than I'd expect.
> The dominant feature of these grazing landscapes is fencing, and I'd
> therefore expect farm dams to appear on a similar scale to fences.
> water=reservoir and landuse=reservoir wouldn't do that.
>
> One of the things I love about OSM is the ability to map incrementally,
> which by definition results in incomplete, lower quality maps that are
> constantly improving. If the priority was a high quality map, we'd map
> systematically (like Missing maps, but for everything that will appear on a
> render) and not release an area until it was done. I wouldn't be mapping.
>
>
> On Thu, 17 Dec 2020, 1:26 am Tomas Straupis, 
> wrote:
>
>> 2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
>> >
>> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
>> > (just added)
>>
>>   Thank you. Maybe it is better to discuss here before adding to wiki?
>>   My arguments on the points you've added:
>>
>>   1. Regarding benefit of having a combining level/tag natural=water.
>> If today you would query all data with natural=water - you will get
>> not only lakes and reservoirs grouped, but also riverbank polygons
>> (totally different beast) and micro elements like water=pond. This
>> could only be partly useful in the largest scale maps and only if you
>> make very simple maps and for some reason use the same symbolisation
>> for such different water classes. For example ponds usually have less
>> complex and less prominent symbolisation because of their size and
>> importance. Riverbanks would not need polygon labelling, but rather
>> use river (central) line for label placement. Most of GIS/Cartography
>> work goes in middle/small scales and it will be impossible to use only
>> natural=water there, you would have to add "and water not in
>> ('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
>> makes it of the same complexity from coding perspective as original
>> water scheme.
>>
>>   2. Very important disadvantage of water=reservoir from
>> cartographic/gis perspective: it allows mappers to NOT differentiate
>> between natural lakes and man made reservoirs. If first point
>> describes how different classes are USED, this second point is about
>> how these classes are CAPTURED.
>>
>>   Did I miss anything?
>>
>> ___
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread Brian M. Sperlongano
Volker,

Thanks for the comments!  For the specific linked case (winding road for
74(!) miles), it seems that is already covered in the proposal -
hazard=curves and its sub-tags cover this, and if it truly is 74
consecutive miles, that I would think it's just fine to tag 74 miles worth
of ways in this way.

With regard to perceived hazards, and degrees of hazards, these are clearly
interesting and complex topics.  I don't know how to address them, but I
like that you're breaking down the problem in a systematic way.  I'm
intrigued and interested in hearing more and/or collaborating on the
topic.  I think we would need to examine a handful of examples to really
understand the space.

That said, I don't think the lack of a generalized approach towards
signed/unsigned/graded hazards should prevent us from formalizing the
30,000 usages of the hazard key.  Mappers have "voted with their tagging"
and we should respect that unless there is a strong reason not to.

On Wed, Dec 16, 2020 at 6:30 PM Volker Schmidt  wrote:

> Brian,
> I am trying to put order in this also in  my own mind.
> I think we should have an approach which is already clearly structured
> towards two things
> A the difference between
> - signposted hazards
> - unsigned hazards perceived by the mappers
> B for hazards that may have different degrees of hazardness (like the
> difficulty classes of hiking paths, MTB tracks, rapids,...)
> we should have solutions that allow a basic tagging plus the option of
> classes of hazardness for advanced mappers
>
> This approach should be put in the hazard proposal, even if at the moment
> the proposal only covers signposted hazards.
>
> Volker
>
> PS be prepared: how do we tag a hazard like this.
> 
>
>
>
>
> On Wed, 16 Dec 2020 at 23:13, Brian M. Sperlongano 
> wrote:
>
>> As the maintainer of the current hazard proposal - I don't really have
>> strong opinions about signed versus unsigned hazards, though I know others
>> do.  However, signed hazards seem to be something that we all agree should
>> be tagged, and this proposal is attempting to approve the collection of
>> usages that we all agree on.  I knew going in that the topic was too big to
>> be able to address every possible hazard that someone might want to tag but
>> we have to start somewhere.
>>
>> So --- consider this proposal a starting point, not the end of the story!
>>
>> There is no reason why hazard tagging can't be expanded from this current
>> base, and since we have free tagging, there is nothing stopping any mapper
>> from either simply inventing their own new hazard tag values or other
>> usages for things not covered, or offering new proposals to expand the
>> usage.
>>
>> On Wed, Dec 16, 2020 at 5:02 PM ael via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>> On Wed, Dec 16, 2020 at 10:22:44PM +0100, Volker Schmidt wrote:
>>> > I see this subject directly related to the "hazard" discussion in the
>>> sense
>>> > that I suggested to clearly define the difference between signposted
>>> > hazards/dangers/warnings and un-signed such situations that are
>>> observable
>>> > on the ground, and therefore are subject also to personal judgement.
>>> With
>>> > other words, beyond the question of how to map it, there is also the
>>> > question of what is a rapid or any other hazard.
>>>
>>> I strongly agree. I was planning to vote against the current hazard
>>> proposal on exactly these grounds. There are clear hazards that
>>> are not necessarily signed. I don't see why we need two different
>>> tags.
>>>
>>> This is slightly off-topic in that I am picking up on the
>>> hazard tag rather than rapids. I see no objection to adding hazard=rapids
>>> although that might be redundant unless there exist rapids that are
>>> not hazardous. I suppose shallow rapids might qualify.
>>>
>>> ael
>>>
>>>
>>>
>>> ___
>>> 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 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] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread stevea
I'm "one more OSM Contributor" volunteering my opinion here.  I voted for the 
hazard proposal as is, although my vote included the note that "this proposal 
is a solid foundation for the (hazard) syntax of both today and tomorrow."

There are such things:  OSM has many examples of where we begin something that 
is a well-thought-out sketch (or more, yet still recognizable as 
not-quite-complete) and then grows to a mature example of itself.  Perfection 
should not be the enemy of the good.  This is at least a good proposal, I'd 
even say "excellent," especially in its efforts to be comprehensive.  I say 
this neither to discourage the continuing good dialog here, nor the growth of 
"hazard" (syntax, wiki, usage in the map data...) into the future, but rather 
in harmony with those.  This puts me in agreement with Brian as he says 
"consider this proposal a starting point."  I'm saying "it's at least a good 
one, I'll even go 'excellent.'"

I believe the more voices we hear, the better.

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


Re: [Tagging] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread Volker Schmidt
Brian,
I am trying to put order in this also in  my own mind.
I think we should have an approach which is already clearly structured
towards two things
A the difference between
- signposted hazards
- unsigned hazards perceived by the mappers
B for hazards that may have different degrees of hazardness (like the
difficulty classes of hiking paths, MTB tracks, rapids,...)
we should have solutions that allow a basic tagging plus the option of
classes of hazardness for advanced mappers

This approach should be put in the hazard proposal, even if at the moment
the proposal only covers signposted hazards.

Volker

PS be prepared: how do we tag a hazard like this.





On Wed, 16 Dec 2020 at 23:13, Brian M. Sperlongano 
wrote:

> As the maintainer of the current hazard proposal - I don't really have
> strong opinions about signed versus unsigned hazards, though I know others
> do.  However, signed hazards seem to be something that we all agree should
> be tagged, and this proposal is attempting to approve the collection of
> usages that we all agree on.  I knew going in that the topic was too big to
> be able to address every possible hazard that someone might want to tag but
> we have to start somewhere.
>
> So --- consider this proposal a starting point, not the end of the story!
>
> There is no reason why hazard tagging can't be expanded from this current
> base, and since we have free tagging, there is nothing stopping any mapper
> from either simply inventing their own new hazard tag values or other
> usages for things not covered, or offering new proposals to expand the
> usage.
>
> On Wed, Dec 16, 2020 at 5:02 PM ael via Tagging 
> wrote:
>
>> On Wed, Dec 16, 2020 at 10:22:44PM +0100, Volker Schmidt wrote:
>> > I see this subject directly related to the "hazard" discussion in the
>> sense
>> > that I suggested to clearly define the difference between signposted
>> > hazards/dangers/warnings and un-signed such situations that are
>> observable
>> > on the ground, and therefore are subject also to personal judgement.
>> With
>> > other words, beyond the question of how to map it, there is also the
>> > question of what is a rapid or any other hazard.
>>
>> I strongly agree. I was planning to vote against the current hazard
>> proposal on exactly these grounds. There are clear hazards that
>> are not necessarily signed. I don't see why we need two different
>> tags.
>>
>> This is slightly off-topic in that I am picking up on the
>> hazard tag rather than rapids. I see no objection to adding hazard=rapids
>> although that might be redundant unless there exist rapids that are
>> not hazardous. I suppose shallow rapids might qualify.
>>
>> ael
>>
>>
>>
>> ___
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rapids (whitewater) on rivers --> Hazards

2020-12-16 Thread Brian M. Sperlongano
As the maintainer of the current hazard proposal - I don't really have
strong opinions about signed versus unsigned hazards, though I know others
do.  However, signed hazards seem to be something that we all agree should
be tagged, and this proposal is attempting to approve the collection of
usages that we all agree on.  I knew going in that the topic was too big to
be able to address every possible hazard that someone might want to tag but
we have to start somewhere.

So --- consider this proposal a starting point, not the end of the story!

There is no reason why hazard tagging can't be expanded from this current
base, and since we have free tagging, there is nothing stopping any mapper
from either simply inventing their own new hazard tag values or other
usages for things not covered, or offering new proposals to expand the
usage.

On Wed, Dec 16, 2020 at 5:02 PM ael via Tagging 
wrote:

> On Wed, Dec 16, 2020 at 10:22:44PM +0100, Volker Schmidt wrote:
> > I see this subject directly related to the "hazard" discussion in the
> sense
> > that I suggested to clearly define the difference between signposted
> > hazards/dangers/warnings and un-signed such situations that are
> observable
> > on the ground, and therefore are subject also to personal judgement. With
> > other words, beyond the question of how to map it, there is also the
> > question of what is a rapid or any other hazard.
>
> I strongly agree. I was planning to vote against the current hazard
> proposal on exactly these grounds. There are clear hazards that
> are not necessarily signed. I don't see why we need two different
> tags.
>
> This is slightly off-topic in that I am picking up on the
> hazard tag rather than rapids. I see no objection to adding hazard=rapids
> although that might be redundant unless there exist rapids that are
> not hazardous. I suppose shallow rapids might qualify.
>
> ael
>
>
>
> ___
> 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] Rapids (whitewater) on rivers

2020-12-16 Thread ael via Tagging
On Wed, Dec 16, 2020 at 10:22:44PM +0100, Volker Schmidt wrote:
> I see this subject directly related to the "hazard" discussion in the sense
> that I suggested to clearly define the difference between signposted
> hazards/dangers/warnings and un-signed such situations that are observable
> on the ground, and therefore are subject also to personal judgement. With
> other words, beyond the question of how to map it, there is also the
> question of what is a rapid or any other hazard.

I strongly agree. I was planning to vote against the current hazard
proposal on exactly these grounds. There are clear hazards that
are not necessarily signed. I don't see why we need two different
tags.

This is slightly off-topic in that I am picking up on the
hazard tag rather than rapids. I see no objection to adding hazard=rapids
although that might be redundant unless there exist rapids that are
not hazardous. I suppose shallow rapids might qualify.

ael



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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Joseph Guillaume
This discussion has convinced me not to use landuse=reservoir.

It sounds like the only benefit is its historical use, whereas I've
personally seen benefits of the natural=water approach.

I've mapped quite a number of farm dams as natural=water without being sure
what subtag to use.
I now think that's because there isn't an appropriate subtag. I definitely
don't want to tag it as a pond. While a farm dam is structurally and
functionally a reservoir, there are clear differences with large reservoirs.

Already now, farm dams tend to be mapped more prominently than I'd expect.
The dominant feature of these grazing landscapes is fencing, and I'd
therefore expect farm dams to appear on a similar scale to fences.
water=reservoir and landuse=reservoir wouldn't do that.

One of the things I love about OSM is the ability to map incrementally,
which by definition results in incomplete, lower quality maps that are
constantly improving. If the priority was a high quality map, we'd map
systematically (like Missing maps, but for everything that will appear on a
render) and not release an area until it was done. I wouldn't be mapping.


On Thu, 17 Dec 2020, 1:26 am Tomas Straupis, 
wrote:

> 2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
> >
> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
> > (just added)
>
>   Thank you. Maybe it is better to discuss here before adding to wiki?
>   My arguments on the points you've added:
>
>   1. Regarding benefit of having a combining level/tag natural=water.
> If today you would query all data with natural=water - you will get
> not only lakes and reservoirs grouped, but also riverbank polygons
> (totally different beast) and micro elements like water=pond. This
> could only be partly useful in the largest scale maps and only if you
> make very simple maps and for some reason use the same symbolisation
> for such different water classes. For example ponds usually have less
> complex and less prominent symbolisation because of their size and
> importance. Riverbanks would not need polygon labelling, but rather
> use river (central) line for label placement. Most of GIS/Cartography
> work goes in middle/small scales and it will be impossible to use only
> natural=water there, you would have to add "and water not in
> ('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
> makes it of the same complexity from coding perspective as original
> water scheme.
>
>   2. Very important disadvantage of water=reservoir from
> cartographic/gis perspective: it allows mappers to NOT differentiate
> between natural lakes and man made reservoirs. If first point
> describes how different classes are USED, this second point is about
> how these classes are CAPTURED.
>
>   Did I miss anything?
>
> ___
> 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] Rapids (whitewater) on rivers

2020-12-16 Thread Volker Schmidt
I see this subject directly related to the "hazard" discussion in the sense
that I suggested to clearly define the difference between signposted
hazards/dangers/warnings and un-signed such situations that are observable
on the ground, and therefore are subject also to personal judgement. With
other words, beyond the question of how to map it, there is also the
question of what is a rapid or any other hazard.
I would like to have a scheme for both situations, i.e. one scheme would be
for mapping signs for officially posted hazards, the other scheme would be
for hazards that the mapper sees on the ground, but without signposting.
In the signposted case the mapper has no role in assessing the presence or
not of the actual hazard, whereas in the second case we need  to establish
how to avoid wildly different meanings of the same tagging.
I'm familiar with two similar problems: mountain hiking and MTB routes. We
have tags for the level of difficulty for both of them (which are directly
related to the possible hazard). I use mountain paths and I ride a normal
touring bike off-asphalt. I can distinguish between, say, the lowest two
levels of difficulty in both cases, but not the higher levels, simply
because I would not go there.
So, transferring that to the rapids,: I can see a rapid in a river, but
cannot access its grade of difficulty (and I am also lacking the knowledge
of how much a river changes with the seasons and the weather).
I am a bit digressing from the posed question, but I think that should also
be taken into account.



On Wed, 16 Dec 2020 at 21:58, Joseph Eisenberg 
wrote:

> In the year 2020 waterway=rapids has been added a couple hundred times,
> and the other two tags whitewater:section_grade and whitewater:rapid_grade
> have been used about 100 times each:
> https://taghistory.raifer.tech/#***/whitewater:rapid_grade/&***/whitewater:section_grade/&***/waterway/rapids
> (zoom in to the most recent yet)
>
> I think both tagging methods have their use. The tag waterway=rapids is
> great to add to a node to specify that there are rapids here, and the
> others are good for expert kayakers and rafters who are able to assess the
> rapid grade.
>
> I don't know enough about the subject to make a proposal to clear things
> up, but the existing tags seem to be fine.
>
> -- Joseph Eisenberg
>
> On Wed, Dec 16, 2020 at 12:35 PM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>> Dec 16, 2020, 19:27 by kevin.b.ke...@gmail.com:
>>
>> The last time I looked, there was no non-deprecated way to map the
>> information that I had.
>>
>> That is sign of bad tagging scheme.
>>
>> I now see that @jeisenbe has restored the `waterway=rapids` tag to the
>> Wiki.
>>
>> Is it enough?
>>
>> I asked here on the mailing list, and the only answers that I got were
>> along the lines of "then don't map it."  So for several years I haven't
>> attempted to map rapids. The ones I know of and want to render, I maintain
>> separately from OSM, because the previous discussion had caused me to label
>> this feature mentally as, "OSM doesn't want this mapped."
>>
>> :( Hopefully this can be fixed so this will not happen.
>> ___
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rapids (whitewater) on rivers

2020-12-16 Thread Brian M. Sperlongano
+1

IMHO these are complementary.  waterway=rapids can be tagged from overhead
imagery, and the additional detail of the rapids can be added later by
people with subject matter expertise.

I see this as equivalent to sac_scale=* for hiking trails - it does not
replace the underlying highway=path, it adds more detail as to the type of
path.

Since both taggings are in use (and one is approved), it is appropriate to
document both.  If someone thinks that waterway=rapids should be
deprecated, I think the burden would be on them to propose that.

On Wed, Dec 16, 2020 at 3:58 PM Joseph Eisenberg 
wrote:

> In the year 2020 waterway=rapids has been added a couple hundred times,
> and the other two tags whitewater:section_grade and whitewater:rapid_grade
> have been used about 100 times each:
> https://taghistory.raifer.tech/#***/whitewater:rapid_grade/&***/whitewater:section_grade/&***/waterway/rapids
> (zoom in to the most recent yet)
>
> I think both tagging methods have their use. The tag waterway=rapids is
> great to add to a node to specify that there are rapids here, and the
> others are good for expert kayakers and rafters who are able to assess the
> rapid grade.
>
> I don't know enough about the subject to make a proposal to clear things
> up, but the existing tags seem to be fine.
>
> -- Joseph Eisenberg
>
> On Wed, Dec 16, 2020 at 12:35 PM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>> Dec 16, 2020, 19:27 by kevin.b.ke...@gmail.com:
>>
>> The last time I looked, there was no non-deprecated way to map the
>> information that I had.
>>
>> That is sign of bad tagging scheme.
>>
>> I now see that @jeisenbe has restored the `waterway=rapids` tag to the
>> Wiki.
>>
>> Is it enough?
>>
>> I asked here on the mailing list, and the only answers that I got were
>> along the lines of "then don't map it."  So for several years I haven't
>> attempted to map rapids. The ones I know of and want to render, I maintain
>> separately from OSM, because the previous discussion had caused me to label
>> this feature mentally as, "OSM doesn't want this mapped."
>>
>> :( Hopefully this can be fixed so this will not happen.
>> ___
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Rapids (whitewater) on rivers

2020-12-16 Thread Joseph Eisenberg
In the year 2020 waterway=rapids has been added a couple hundred times, and
the other two tags whitewater:section_grade and whitewater:rapid_grade have
been used about 100 times each:
https://taghistory.raifer.tech/#***/whitewater:rapid_grade/&***/whitewater:section_grade/&***/waterway/rapids
(zoom in to the most recent yet)

I think both tagging methods have their use. The tag waterway=rapids is
great to add to a node to specify that there are rapids here, and the
others are good for expert kayakers and rafters who are able to assess the
rapid grade.

I don't know enough about the subject to make a proposal to clear things
up, but the existing tags seem to be fine.

-- Joseph Eisenberg

On Wed, Dec 16, 2020 at 12:35 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 16, 2020, 19:27 by kevin.b.ke...@gmail.com:
>
> The last time I looked, there was no non-deprecated way to map the
> information that I had.
>
> That is sign of bad tagging scheme.
>
> I now see that @jeisenbe has restored the `waterway=rapids` tag to the
> Wiki.
>
> Is it enough?
>
> I asked here on the mailing list, and the only answers that I got were
> along the lines of "then don't map it."  So for several years I haven't
> attempted to map rapids. The ones I know of and want to render, I maintain
> separately from OSM, because the previous discussion had caused me to label
> this feature mentally as, "OSM doesn't want this mapped."
>
> :( Hopefully this can be fixed so this will not happen.
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging



Dec 16, 2020, 19:27 by kevin.b.ke...@gmail.com:

> The last time I looked, there was no non-deprecated way to map the 
> information that I had.
>
That is sign of bad tagging scheme.

> I now see that @jeisenbe has restored the `waterway=rapids` tag to the Wiki.  
>
Is it enough?

> I asked here on the mailing list, and the only answers that I got were along 
> the lines of "then don't map it."  So for several years I haven't attempted 
> to map rapids. The ones I know of and want to render, I maintain separately 
> from OSM, because the previous discussion had caused me to label this feature 
> mentally as, "OSM doesn't want this mapped."
>
:( Hopefully this can be fixed so this will not happen.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Kevin Kenny
On Wed, Dec 16, 2020 at 1:24 PM Tomas Straupis 
wrote:

>   This might be correct. I guess it depends on direction you look at
> it: what is exception from the reservoir rule - hard shoreline or non
> hard. I was thinking of the ways to map fuzzy shore in OSM and had the
> same idea to tag fuzzy shoreline as a line - this would be the same
> way as in your example but would need to de-emphasize rather than
> emphasize the shoreline. And I'm sure I've seen a legend with blackish
> border for reservoir, but do not remember if that was USGS or NATO map
> (reservoirs have some distinct properties worth depicting on some
> specific maps)... And I remember talking about lake/reservoir black
> border symbolisation with one of the leading cartography experts in
> Lithuania.
>

In my part of the world, the most significant reservoirs are the large ones
of the New York City water system (some of which are a couple of hundred km
from the city itself), and the Great Sacandaga Lake. They have hardened
shorelines only near the dams or where the reinforcement is needed to
protect a feature such as a highway. Otherwise, if you couldn't see the
dams (and the signage!) they'd be hard to distinguish from natural lakes.

Where I have good hydrology data, I render normal seasonal limits (by
drawing two shorelines), the presence or absence of emergent vegetation,
and the flood stage (a dashed blue line).  That makes for a pretty complex
(and somewhat 'cubistic') rendering, as at
https://kbk.is-a-geek.net/catskills/test4.html?la=43.5897=-74.6176=15,
but at least gives me some idea how likely I am to get my feet wet. (Or
drown, in the wrong season!)

I have no plans to get any of the data behind this rendering into OSM. I've
managed imports before. I might again. I'm not going to attempt one on this
scale, particularly when I'm not certain about the data quality.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 20:30 Kevin Kenny rašė:
>>   https://upes.openmap.lt/#17/56.296411/22.330154
> Looks good, I think... but what is the tagging?

  waterway=rapid
  At the time of usage it was deprecated (and plural), but I know what
that means and after each discussion on tagging list I'm less and less
inclined to propose/discuss anything here and evenmore editing the
wiki.

  My take is that cayaking info is added to be used for specific
purposes (well, cayaking) by specific people (cayaking enthusiasts,
cayaking service providers and tourists) so we know the practical
usage, we know cartographic requirements for data, look for suitable
tags in other places and use them, if there are none or they do not
fit the purpose - we add required tags. Important thing is that we can
distinguish each feature and if some more suitable tagging schema
emerges - we can always re-tag everything in a minute (and change
software in a day).

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


Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

2020-12-16 Thread François Lacombe
Hi Brian

Le mar. 15 déc. 2020 à 00:57, Brian M. Sperlongano  a
écrit :

> The wiki[1] says: "OpenStreetMap does not have 'banned features', as
> anybody is allowed and encouraged to use any tag they think is useful."
> Therefore, deprecating a feature does not "enforce or forbid" the use of a
> tag - all it does is set the tag's status to deprecated on the tag's wiki
> page, and adds an entry to the deprecated features[1] page.
>

Got it thank you
Then I've updated the proposal and changed to pump:type deprecation.

All the best

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Kevin Kenny
On Wed, Dec 16, 2020 at 12:58 PM Tomas Straupis 
wrote:

>   Why? Cayaking info is pretty rare - opposite of lake/reservoir data.
> Therefore it's fine to map what you need only:
>   https://upes.openmap.lt/#17/56.296411/22.330154


Looks good, I think... but what is the tagging?

An example (with part of the hydrography and nearly all of the landcover
from non-OSM sources) follows. I'm rendering polygons of the river with a
white overlay when they are stretches of rapids.  The rapids can be short
and relatively discrete as at
https://kbk.is-a-geek.net/catskills/test4.html?la=43.3152=-73.8440=15
In the mountains, though, there may be long stretches of nearly continuous
whitewater:
https://kbk.is-a-geek.net/catskills/test4.html?la=43.3604=-74.3637=14
The last time I looked, there was no non-deprecated way to map the
information that I had.

I now see that @jeisenbe has restored the `waterway=rapids` tag to the
Wiki.

At the time I last had the discussion, the version of the page on the Wiki
looked like
https://wiki.openstreetmap.org/w/index.php?title=Tag:waterway%3Drapids=1322133
- deprecating the tag.  On the other hand, the discussion on
https://wiki.openstreetmap.org/wiki/Whitewater_sports is highly technical.
I know that I am not skilled enough at whitewater paddling (I did a little
in my youth, but my youth is quite a long time ago) to make a safe
assessment of grade, and the `Whtiewater sports' page makes no mention of
'grade=unknown'. I asked here on the mailing list, and the only answers
that I got were along the lines of "then don't map it."  So for several
years I haven't attempted to map rapids. The ones I know of and want to
render, I maintain separately from OSM, because the previous discussion had
caused me to label this feature mentally as, "OSM doesn't want this mapped."


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 20:03 Kevin Kenny  rašė:
> Many smaller reservoirs have artificially hardened shorelines completely
> surrounding them, which could be why you thought that the symbology
> distinguishes 'lake' from 'reservoir.'

  This might be correct. I guess it depends on direction you look at
it: what is exception from the reservoir rule - hard shoreline or non
hard. I was thinking of the ways to map fuzzy shore in OSM and had the
same idea to tag fuzzy shoreline as a line - this would be the same
way as in your example but would need to de-emphasize rather than
emphasize the shoreline. And I'm sure I've seen a legend with blackish
border for reservoir, but do not remember if that was USGS or NATO map
(reservoirs have some distinct properties worth depicting on some
specific maps)... And I remember talking about lake/reservoir black
border symbolisation with one of the leading cartography experts in
Lithuania.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Kevin Kenny
On Wed, Dec 16, 2020 at 12:27 PM Tomas Straupis 
wrote:

>   In other maps reservoirs (US?) could have black border.


The usual symbology on USGS and DMS maps is that the black border denotes
an 'artificial shoreline', where the shore is either stabilized with riprap
or concrete, or built up with a groyne, quay or similar structure.

Sometimes I care enough to map those. (No apologies for not caring. There's
so very much around me that is unmapped that anything I do is leaving
something else undone.)  The stabilized shorelines even look decent on the
default rendering.

https://www.openstreetmap.org/#map=16/42.4601/-74.4525
https://www.openstreetmap.org/#map=16/42.4769/-74.4393

Many smaller reservoirs have artificially hardened shorelines completely
surrounding them, which could be why you thought that the symbology
distinguishes 'lake' from 'reservoir.'

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 19:44 Kevin Kenny rašė:
> With respect to water, another concern  of mine is that our tagging schema 
> does not
> offer any way to tag that there are rapids in a river without knowing how to 
> grade the
> difficulty of a canoe or kayak run.

  Why? Cayaking info is pretty rare - opposite of lake/reservoir data.
Therefore it's fine to map what you need only:
  https://upes.openmap.lt/#17/56.296411/22.330154

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Kevin Kenny
On Wed, Dec 16, 2020 at 11:52 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Re: "natural=water' wins.  I can see that there's water there"
>
> You still have to distinguish marine water (outside of the
> natural=coastline) from inland waters, and distinguishing rivers from lakes
> is very important for proper rendering of many maps.
>

I do know that the coastline is a special case, and I know about the
'water=*' key. I fill a value in when I know the answer. I leave it out
when I don't.


> Also, many areas of natural=water actually don't have any water for much
> of the year, if they are also intermittent=yes - such as seasonal lakes in
> semi-arid areas.
>

I use that tag too.

I personally am not as concerned about water=reservoir for artificial
> lakes, but I am concerned that water=river is often forgotten when mapping
> areas of river water, where previously waterway=riverbank was clearly
> distinguished from lakes.
>
> Many map styles distinguish rivers and streams from lakes, since it is
> often helpful to use a darker color for narrow linear features.
>

That's fine. I can see that it's moving water and tag it appropriately.

If I have to figure out if a pond is karstic, glacial, man-made or
beaver-made before I can map it, it's likely to go unmapped. I can't always
see that from aerials and I can't always access the outlet to figure out
what's retaining the water.

We seem to be dividing into two camps here, as we do on many tagging
issues. One camp is, "we must have the highest possible quality. Everything
must be mapped perfectly or not mapped at all." The other is, "it's all
right to have some missing details, they can be filled in later. It's
better to fill in the picture with broad brush strokes and then go back to
add the details."The perfectionists appear to support tagging schemata
that make it difficult to map without complete research. Both sides appear
to agree that doing the research is desirable. It comes down to an
apparently irreconcilable argument over whether it's worse to have an
incompletely characterized waterbody or a blank spot on the map.

With respect to water, another concern  of mine is that our tagging schema
does not offer any way to tag that there are rapids in a river without
knowing how to grade the difficulty of a canoe or kayak run. That's a case
where the voted-on tagging requires perfect mapping before the data can be
entered at all - and when I mentioned that once before, I was put down with
"if you don't understand it, don't map it." I understand it well enough to
know that as a greenwater canoeist, I'll want to portage around it. I can
see the whitewater. I cannot grade it safely. Here, however, the community
consensus appears to have settled on the perfectionist approach, so I don't
map rapids.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 18:58 Ture Pålsson via Tagging rašė:
> Could you elaborate a bit on what cartographic features on that map are
> possible or impossible with the different reservoir tagging schemes?

  Symbolisation (colour), selection (different classes for different scales).
  In other maps reservoirs (US?) could have black border.
  GIS analysis is another beast where these classes are important as different.

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


Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Paul Johnson
On Wed, Dec 16, 2020 at 10:57 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Re: "If only we could be this nimble on long standing things like
> sunsetting ref=* on ways in favor of routes"
>
> Handling ref on routes and ways at the same time requires some more
> complicated processing, and for a long time osm2pgsql did not provide a
> standard way to do this in a consistent manner, until earlier this year. It
> should soon be possible, see
> https://github.com/openstreetmap/osm2pgsql/releases/tag/1.3.0 and
> implementation issues at
> https://github.com/gravitystorm/openstreetmap-carto/issues/596 and
> https://github.com/gravitystorm/openstreetmap-carto/issues/4112 and
>

Well, this is happy news!  Glad to hear it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Joseph Eisenberg
Re: "If only we could be this nimble on long standing things like
sunsetting ref=* on ways in favor of routes"

Handling ref on routes and ways at the same time requires some more
complicated processing, and for a long time osm2pgsql did not provide a
standard way to do this in a consistent manner, until earlier this year. It
should soon be possible, see
https://github.com/openstreetmap/osm2pgsql/releases/tag/1.3.0 and
implementation issues at
https://github.com/gravitystorm/openstreetmap-carto/issues/596 and
https://github.com/gravitystorm/openstreetmap-carto/issues/4112 and

On Wed, Dec 16, 2020 at 8:02 AM Paul Johnson  wrote:

> On Wed, Dec 16, 2020 at 9:34 AM Tom Pfeifer 
> wrote:
>
>> Both tagging and wiki develop, hopefully forward. In this case,
>> Key:destination:ref redirects
>> onto an old 2012 proposal, I'm probably going to resolve that soon with
>> describing the current practice.
>>
>
> Thank you!  If only we could be this nimble on long standing things like
> sunsetting ref=* on ways in favor of routes (one of the things that
> relations were introduced to fix, as routes and their ways are usually
> distinct entities) and fixing lanes=* to actually mean what it says...
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Ture Pålsson via Tagging


> 16 dec. 2020 kl. 17:25 skrev Tomas Straupis :
> 
> What about maps made according to Cartographic conventions?
>  You know, something on the lines of: https://map.geo.admin.ch 
>  Would
> it be possible to make maps of such quality writing general queries
> like natural=water?

Could you elaborate a bit on what cartographic features on that map are 
possible or impossible with the different reservoir tagging schemes? Being 
Swedish, not Swiss, makes it hard for me to know what to look for.

(For the record, I have no particular opinion in this question, except that I 
think OSM should immediately adapt its tagging to the Swedish Terrängkartan, T5 
edition, but I think that’s going to be a hard sell! :-) )

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Joseph Eisenberg
Re: "natural=water' wins.  I can see that there's water there"

You still have to distinguish marine water (outside of the
natural=coastline) from inland waters, and distinguishing rivers from lakes
is very important for proper rendering of many maps.

Also, many areas of natural=water actually don't have any water for much of
the year, if they are also intermittent=yes - such as seasonal lakes in
semi-arid areas.

I personally am not as concerned about water=reservoir for artificial
lakes, but I am concerned that water=river is often forgotten when mapping
areas of river water, where previously waterway=riverbank was clearly
distinguished from lakes.

Many map styles distinguish rivers and streams from lakes, since it is
often helpful to use a darker color for narrow linear features.

-- Joseph Eisenberg

On Wed, Dec 16, 2020 at 8:40 AM Kevin Kenny  wrote:

> My take on it:
>
> Wearing my data consumer's hat:
>
> For most purposes, I care about "this ground is covered with water".
> 'natural=water' is the main thing to look for, but I also have to look for
> 'landuse=reservoir' and several other things that I can't be bothered to
> look up at the moment. I have to look for all those things, so I don't
> really care all that much which one is in use.
>
> The chief problem with both of these tags is that even for the rough-level
> mapping, I have to examine 'water=*' or 'reservior_type=*' to find that the
> contained substance is, in fact, water and not sewage or mine tailings.
>
> In any case, both uses are widespread.  I'm going to need to interpret
> both for the foreseeable future.  I can cope with synonyms.  I'm not going
> to lobby strongly for one or the other.
>
> Wearing my mapper's hat:
>
> 'natural=water' wins.  I can see that there's water there. The big
> counterargument that I've heard, other than that 'landuse=reservoir' has
> been the predominant tagging, is that a reservoir isn't "natural" water.
> But in our complex, human- (and beaver-) sculpted environment, what is
> natural?  Many of the reservoirs that I've encountered have natural lakes
> and ponds underneath, and simply have had their water raised. It seems to
> me that by the thinking of those who think that 'natural' means "totally
> untouched by humans", that I'd actually be required to do the research
> about where the old shoreline lay before humans raised the water, and
> divide the reservoir into an inner 'natural=water' and an outer
> 'landuse=reservoir' - which is an example of the tagging position that I
> abhor.  I shouldn't have to do historical research in order to map
> something that I can directly observe with my own eyes. In fact, with some
> of the ponds I've mapped, I've not troubled (or been able to) access the
> outlet to find out what controls the water level. I don't know whether they
> are tarns, dolines, beaver ponds, or man-made ponds created for logging
> until I can find out where the water goes when it leaves.  (I hike in
> glaciated karst; the landforms are complex.) But I can see at a  glance,
> "there's water here," whether glaciers, limestone, beavers or humans put it
> there. That should be enough to map it.
>
> If someone else feels strongly enough about it to change something that
> I've mapped as 'natural=water' to 'landuse=reservoir', well, I know that I
> have to accept that as a synonym. so it's not going to harm me as a data
> consumer.  I'm not going to change it back.  But I'm not going to accept
> that the original tagging was "incorrect" or "deprecated".  I mapped what I
> saw. You can go there and see it too.
>
> To continue the classification of waterbodies, this argument to me is a
> tempest in a teapot.
> --
> 73 de ke9tv/2, Kevin
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Kevin Kenny
My take on it:

Wearing my data consumer's hat:

For most purposes, I care about "this ground is covered with water".
'natural=water' is the main thing to look for, but I also have to look for
'landuse=reservoir' and several other things that I can't be bothered to
look up at the moment. I have to look for all those things, so I don't
really care all that much which one is in use.

The chief problem with both of these tags is that even for the rough-level
mapping, I have to examine 'water=*' or 'reservior_type=*' to find that the
contained substance is, in fact, water and not sewage or mine tailings.

In any case, both uses are widespread.  I'm going to need to interpret both
for the foreseeable future.  I can cope with synonyms.  I'm not going to
lobby strongly for one or the other.

Wearing my mapper's hat:

'natural=water' wins.  I can see that there's water there. The big
counterargument that I've heard, other than that 'landuse=reservoir' has
been the predominant tagging, is that a reservoir isn't "natural" water.
But in our complex, human- (and beaver-) sculpted environment, what is
natural?  Many of the reservoirs that I've encountered have natural lakes
and ponds underneath, and simply have had their water raised. It seems to
me that by the thinking of those who think that 'natural' means "totally
untouched by humans", that I'd actually be required to do the research
about where the old shoreline lay before humans raised the water, and
divide the reservoir into an inner 'natural=water' and an outer
'landuse=reservoir' - which is an example of the tagging position that I
abhor.  I shouldn't have to do historical research in order to map
something that I can directly observe with my own eyes. In fact, with some
of the ponds I've mapped, I've not troubled (or been able to) access the
outlet to find out what controls the water level. I don't know whether they
are tarns, dolines, beaver ponds, or man-made ponds created for logging
until I can find out where the water goes when it leaves.  (I hike in
glaciated karst; the landforms are complex.) But I can see at a  glance,
"there's water here," whether glaciers, limestone, beavers or humans put it
there. That should be enough to map it.

If someone else feels strongly enough about it to change something that
I've mapped as 'natural=water' to 'landuse=reservoir', well, I know that I
have to accept that as a synonym. so it's not going to harm me as a data
consumer.  I'm not going to change it back.  But I'm not going to accept
that the original tagging was "incorrect" or "deprecated".  I mapped what I
saw. You can go there and see it too.

To continue the classification of waterbodies, this argument to me is a
tempest in a teapot.
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 18:04 Mateusz Konieczny via Tagging rašė:
> Then I can you show some map style that do it differently and
> render all types of water areas in the same way (some
> render also labels in the same way, with exception
> for linear features)

  BTW. It is another advantage of landuse=reservoir schema. It forces
people creating map to understand that there ARE different classes of
water. Then they have to understand what those classes are (and why)
and choose which are appropriate in their particular products. If you
have an umbrella tag like natural=water most will simply go with such
simple where condition and therefore miss some very important things
(and create low quality maps, and will not learn important lessons).

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Florimond Berthoux
Hello,

Le mer. 16 déc. 2020 à 16:19, Brian M. Sperlongano  a
écrit :

> If you are not willing to have this question put up for a proposal (where,
> as with any proposal, you are free to present your argument for all to
> consider), your arguments are in bad faith, and again, must be dismissed
> without consideration.  Your desire to bypass our democratic process and
> upend community consensus for tagging you don't like is frankly insulting
> to the rest of us that work hard to achieve consensus in tagging.  Why
> should we waste time debating you, if you aren't willing to accept the
> outcome of the community decision-making process?
>

There are no such things as "democratic process" or "community consensus"
in tagging in OSM.
So please, we must be tolerant with others' freedom to express their
opinions.

Bien à vous.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 18:04 Mateusz Konieczny via Tagging rašė:
> Then I can you show some map style that do it differently and
> render all types of water areas in the same way (some
> render also labels in the same way, with exception
> for linear features)
> https://www.openstreetmap.org/#map=14/54.3643/18.7150
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=C
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=T
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=H

  Why is there no label for waterway polygon?
  What about maps made according to Cartographic conventions?
  You know, something on the lines of: https://map.geo.admin.ch Would
it be possible to make maps of such quality writing general queries
like natural=water?

  A lot of Cartographic papers are open. Look at those mentioning VGI
or OSM directly and check what cartographers very diplomatically say
about OSM maps/cartography (not data). Why is that? Could it be that
there is simply too much resistance to push something more advanced
into OSM?

>> Best system is to use codes, not names for keys/values, but that is a
>> totally different "saga".
> Feel free to propose this one.

  From my perspective there is a big problem with making complex
changes/decisions (requiring a lot of specific/thematic
knowledge/experience) as there is no way to value "votes" of people
with different experience differently. If it is not valued differently
then the result you get is an average. What is an average of 1, 1, 1,
2, 2, 50? Why would 50 want to be involved in something where result
will be 10 and you would have to fight for each action?

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Peter Elderson
I'll tag both ways then, or better map none at all? Shirt, another dilemma.
I need something stronger than tea.

Peter Elderson


Op wo 16 dec. 2020 om 17:04 schreef Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

> Dec 16, 2020, 16:49 by tomasstrau...@gmail.com:
>
> 2020-12-16, tr, 17:04 Mateusz Konieczny via Tagging rašė:
>
> I agree that it is useful only for primitive rendering of water areas
> (that possibly filters water areas by area but does not distinguish
> between lakes and rivers). It may be worth mentioning.
>
> But it is also the most typical and common way of rendering things.
>
>
> How do you decide that it is most typical and common way of rendering
> things?
> ALL maps I created or seen in GIS/Cartography world, be it online or
> printed, interpret water classes differently, especially
> basins/riverbanks...
>
> Then I can you show some map style that do it differently and
> render all types of water areas in the same way (some
> render also labels in the same way, with exception
> for linear features)
>
> https://www.openstreetmap.org/#map=14/54.3643/18.7150
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=C
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=T
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=H
> 
>
> In contrast
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=O
> 
> appears to distinguish seas/oceans
>
> Best system is to use codes, not names for keys/values, but that is a
> totally different "saga".
>
> Feel free to propose this one.
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging
Dec 16, 2020, 16:49 by tomasstrau...@gmail.com:

> 2020-12-16, tr, 17:04 Mateusz Konieczny via Tagging rašė:
>
>> I agree that it is useful only for primitive rendering of water areas
>> (that possibly filters water areas by area but does not distinguish
>> between lakes and rivers). It may be worth mentioning.
>>
>> But it is also the most typical and common way of rendering things.
>>
>
> How do you decide that it is most typical and common way of rendering things?
>  ALL maps I created or seen in GIS/Cartography world, be it online or
> printed, interpret water classes differently, especially
> basins/riverbanks... 
>
Then I can you show some map style that do it differently and 
render all types of water areas in the same way (some 
render also labels in the same way, with exception
for linear features)

https://www.openstreetmap.org/#map=14/54.3643/18.7150
https://www.openstreetmap.org/#map=14/54.3666/18.7138=C
https://www.openstreetmap.org/#map=14/54.3666/18.7138=T
https://www.openstreetmap.org/#map=14/54.3666/18.7138=H 


In contrast
https://www.openstreetmap.org/#map=14/54.3666/18.7138=O 

appears to distinguish seas/oceans


> Best system is to use codes, not names for keys/values, but that is a
> totally different "saga".
>
Feel free to propose this one.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Paul Johnson
On Wed, Dec 16, 2020 at 9:34 AM Tom Pfeifer  wrote:

> Both tagging and wiki develop, hopefully forward. In this case,
> Key:destination:ref redirects
> onto an old 2012 proposal, I'm probably going to resolve that soon with
> describing the current practice.
>

Thank you!  If only we could be this nimble on long standing things like
sunsetting ref=* on ways in favor of routes (one of the things that
relations were introduced to fix, as routes and their ways are usually
distinct entities) and fixing lanes=* to actually mean what it says...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 17:19 Brian M. Sperlongano rašė:
> The statistics reflect all areas, regardless of which editors were used to 
> create them.
>  I stand by them, as numbers do not lie.

  Have you heard of the saying "correlation is not causation"?
  You have to understand where numbers come from and why in order to use them.

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


Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Mateusz Konieczny via Tagging
OSM Wiki is "dedicated wiki that documents current practices"

Yes, it is sometimes outdated - but it is unlikely to be changed by creating an 
exact duplicate.

If you see something wrong you are welcome to edit it (feel free to ask for help
if you need it).

Dec 16, 2020, 16:49 by o...@dead10ck.com:

> Right, this is what I was thinking as well, it makes a lot of sense to have 
> the direction that's on the sign post to aid with navigation. It seems a 
> dedicated wiki that documents current practices would be helpful. Thank you!
> -- 
> Skyler
>
> On Wed, 2020-12-16 at 16:33 +0100, Tom Pfeifer wrote:
>
>> On 16.12.2020 14:19, Skyler Hawthorne wrote:
>>
>>>
>>> On Wed, Dec 16, 2020, at 05:44, Tom Pfeifer wrote:
>>>
 What is written on the sign at this junction? If "North" is mentioned 
 there I would be
 happy enough with the tagging above.

>>>
>>> That is correct, the sign says "I 787 North". However the wiki page for the 
>>> destination:ref key states:
>>>
>>> The key destination:ref <
>>> https://wiki.openstreetmap.org/wiki/Key:destination:ref>=*
>>>  should be
>>> used to specify the reference of the roads directly ahead as indicated 
>>> on signposts, road
>>> markings or similar. The value of this key should be equal to the value 
>>> of the key ref
>>> <
>>> https://wiki.openstreetmap.org/wiki/Key:ref>=*
>>>  of these roads.
>>>
>>> Note the last sentence. If the destination:ref must be the same as the ref 
>>> it is going to, then this 
>>> would be I 787, or else all the ways along the entire I 787 route should 
>>> have their ref tags changed 
>>> to indicate direction as well.
>>>
>>
>> Well, it says 'should', not 'must', thus in this case using 
>> destination:ref="I 787 North" is a 
>> refinement of just "I 787". Maybe an improvement for the phrase in the wiki 
>> would be
>> "should be equal to or a further qualification of related to the value...".
>>
>> On 16.12.2020 15:41, Paul Johnson wrote:
>>  > Wouldn't it make more sense, and isn't it already more common, for 
>> destination tags to contain the
>>  > information on the destination signs, which /do/ differentiate direction?
>>
>> Haven't analysed that, but if the destinations are signposted that way, it 
>> should be reflected in
>> the tagging.
>>
>>  > I feel like this is another example of "the wiki was written by someone 
>> with inadequate information."
>>
>> Both tagging and wiki develop, hopefully forward. In this case, 
>> Key:destination:ref redirects
>> onto an old 2012 proposal, I'm probably going to resolve that soon with 
>> describing the current practice.
>>
>>   tom
>>
>>
>> ___
>> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 17:04 Mateusz Konieczny via Tagging rašė:
> I agree that it is useful only for primitive rendering of water areas
> (that possibly filters water areas by area but does not distinguish
> between lakes and rivers). It may be worth mentioning.
>
> But it is also the most typical and common way of rendering things.

  How do you decide that it is most typical and common way of rendering things?
  ALL maps I created or seen in GIS/Cartography world, be it online or
printed, interpret water classes differently, especially
basins/riverbanks... And it will be even more important moving to
vector tiles.

> This is a double edged sword, it also means that mapper unsure
> whatever something is natural or man made (common in case
> of mapping based on aerial images, sometimes even in
> case of survey) is unable to mark a water area.

  But that is a point, mapper should find out if we want to have
higher quality data. There is usually some source available you can
use. You can always add fixme, if you're unsure.
  And for the case of pond it IS possible to distinguish it from
reservoir/lake straight away.

> And distinguishing natural vs man made is still possible
> with water tag anyway.

  99% water objects mapped with iD I've seen are water=pond...

> (similarly like I have not mentioned that both natural
> and landuse are quite counterintuitive key names here)

 Best system is to use codes, not names for keys/values, but that is a
totally different "saga".

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


Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Skyler Hawthorne
Right, this is what I was thinking as well, it makes a lot of sense to
have the direction that's on the sign post to aid with navigation. It
seems a dedicated wiki that documents current practices would be
helpful. Thank you!
On Wed, 2020-12-16 at 16:33 +0100, Tom Pfeifer wrote:
> On 16.12.2020 14:19, Skyler Hawthorne wrote:
> > On Wed, Dec 16, 2020, at 05:44, Tom Pfeifer wrote:
> > > What is written on the sign at this junction? If "North" is
> > > mentioned there I would behappy enough with the tagging above.
> > 
> > That is correct, the sign says "I 787 North". However the wiki page
> > for the destination:ref key states:
> > The key destination:ref <
> > https://wiki.openstreetmap.org/wiki/Key:destination:ref>=* should
> > beused to specify the reference of the roads directly ahead as
> > indicated on signposts, roadmarkings or similar. The value of
> > this key should be equal to the value of the key ref<
> > https://wiki.openstreetmap.org/wiki/Key:ref>=* of these roads.
> > Note the last sentence. If the destination:ref must be the same as
> > the ref it is going to, then this would be I 787, or else all the
> > ways along the entire I 787 route should have their ref tags
> > changed to indicate direction as well.
> 
> Well, it says 'should', not 'must', thus in this case using
> destination:ref="I 787 North" is a refinement of just "I 787". Maybe
> an improvement for the phrase in the wiki would be"should be equal to
> or a further qualification of related to the value...".
> On 16.12.2020 15:41, Paul Johnson wrote: > Wouldn't it make more
> sense, and isn't it already more common, for destination tags to
> contain the > information on the destination signs, which /do/
> differentiate direction?
> Haven't analysed that, but if the destinations are signposted that
> way, it should be reflected inthe tagging.
>  > I feel like this is another example of "the wiki was written by
> someone with inadequate information."
> Both tagging and wiki develop, hopefully forward. In this case,
> Key:destination:ref redirectsonto an old 2012 proposal, I'm probably
> going to resolve that soon with describing the current practice.
>   tom
> 
> ___Tagging mailing 
> listtagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-- 
Skyler
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Tom Pfeifer

On 16.12.2020 14:19, Skyler Hawthorne wrote:


On Wed, Dec 16, 2020, at 05:44, Tom Pfeifer wrote:

What is written on the sign at this junction? If "North" is mentioned there I 
would be
happy enough with the tagging above.


That is correct, the sign says "I 787 North". However the wiki page for the 
destination:ref key states:

The key destination:ref 
=* should be
used to specify the reference of the roads directly ahead as indicated on 
signposts, road
markings or similar. The value of this key should be equal to the value of 
the key ref
=* of these roads.

Note the last sentence. If the destination:ref must be the same as the ref it is going to, then this 
would be I 787, or else all the ways along the entire I 787 route should have their ref tags changed 
to indicate direction as well.


Well, it says 'should', not 'must', thus in this case using destination:ref="I 787 North" is a 
refinement of just "I 787". Maybe an improvement for the phrase in the wiki would be

"should be equal to or a further qualification of related to the value...".

On 16.12.2020 15:41, Paul Johnson wrote:
> Wouldn't it make more sense, and isn't it already more common, for 
destination tags to contain the
> information on the destination signs, which /do/ differentiate direction?

Haven't analysed that, but if the destinations are signposted that way, it 
should be reflected in
the tagging.

> I feel like this is another example of "the wiki was written by someone with 
inadequate information."

Both tagging and wiki develop, hopefully forward. In this case, 
Key:destination:ref redirects
onto an old 2012 proposal, I'm probably going to resolve that soon with 
describing the current practice.

 tom


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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Brian M. Sperlongano
The statistics reflect all areas, regardless of which editors were used to
create them.  I stand by them, as numbers do not lie.  There was a 3:1
preference for water=reservoir during 2017 and 2018, two years prior to the
change in iD preset.  The data is open, and taginfo provides a very helpful
REST API.  Feel free to conduct your own statistical analysis.

If you are not willing to have this question put up for a proposal (where,
as with any proposal, you are free to present your argument for all to
consider), your arguments are in bad faith, and again, must be dismissed
without consideration.  Your desire to bypass our democratic process and
upend community consensus for tagging you don't like is frankly insulting
to the rest of us that work hard to achieve consensus in tagging.  Why
should we waste time debating you, if you aren't willing to accept the
outcome of the community decision-making process?

On Wed, Dec 16, 2020 at 9:43 AM Tomas Straupis 
wrote:

> Brian, you're using statistics which DO NOT represent mappers preferences.
> If you would use only JOSM created objects - then it would be close to
> mappers preferences (as JOSM allows mappers to choose).
> But you use iD created/adjusted objects and as it does not allow
> showing your preference (drilling down into tags is only a theoretical
> possibility) and even pushes you to overwrite other peoples
> preferences you have to exclude iD tainted objects if you're trying to
> get "community preference" from statistics.
>
> Therefore I would suggest starting with the core - arguments
> advantages/disadvantages of both schemas.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging



Dec 16, 2020, 15:22 by tomasstrau...@gmail.com:

> 2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
>
>> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
>> (just added)
>>
>
> Thank you. Maybe it is better to discuss here before adding to wiki?
>  
>
In my experience it results just in not adding anything at all.

It is wiki and can be edited by anyone, so if what I added is wrong it can be 
changed.

>
>
> My arguments on the points you've added:
>
>  1. Regarding benefit of having a combining level/tag natural=water.
> If today you would query all data with natural=water - you will get
> not only lakes and reservoirs grouped, but also riverbank polygons
> (totally different beast) and micro elements like water=pond. This
> could only be partly useful in the largest scale maps and only if you
> make very simple maps and for some reason use the same symbolisation
> for such different water classes. For example ponds usually have less
> complex and less prominent symbolisation because of their size and
> importance. Riverbanks would not need polygon labelling, but rather
> use river (central) line for label placement. Most of GIS/Cartography
> work goes in middle/small scales and it will be impossible to use only
> natural=water there, you would have to add "and water not in
> ('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
> makes it of the same complexity from coding perspective as original
> water scheme.
>
I agree that it is useful only for primitive rendering of water areas
(that possibly filters water areas by area but does not distinguish
between lakes and rivers). It may be worth mentioning.

But it is also the most typical and common way of rendering things.

>  2. Very important disadvantage of water=reservoir from
> cartographic/gis perspective: it allows mappers to NOT differentiate
> between natural lakes and man made reservoirs. If first point
> describes how different classes are USED, this second point is about
> how these classes are CAPTURED.
>
This is a double edged sword, it also means that mapper unsure
whatever something is natural or man made (common in case
of mapping based on aerial images, sometimes even in
case of survey) is unable to mark a water area.

And distinguishing natural vs man made is still possible 
with water tag anyway.

I was unsure whatever it should be listed as a benefit or
drawback or both sides explained so I ended not 
mentioning this.

(similarly like I have not mentioned that both natural
and landuse are quite counterintuitive key names here)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Paul Johnson
On Wed, Dec 16, 2020 at 7:20 AM Skyler Hawthorne  wrote:

> Note the last sentence. If the destination:ref must be the same as the ref
> it is going to, then this would be I 787, or else all the ways along the
> entire I 787 route should have their ref tags changed to indicate direction
> as well.
>

Wouldn't it make more sense, and isn't it already more common, for
destination tags to contain the information on the destination signs, which
*do* differentiate direction?  This ends up as an important distinction
particularly at freeway interchanges, where, say, going southbound, the
ramp to westbound is a left exit instead and eastbound is a right exit,
opposite driver expectation.

I feel like this is another example of "the wiki was written by someone
with inadequate information."
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
Brian, you're using statistics which DO NOT represent mappers preferences.
If you would use only JOSM created objects - then it would be close to
mappers preferences (as JOSM allows mappers to choose).
But you use iD created/adjusted objects and as it does not allow
showing your preference (drilling down into tags is only a theoretical
possibility) and even pushes you to overwrite other peoples
preferences you have to exclude iD tainted objects if you're trying to
get "community preference" from statistics.

Therefore I would suggest starting with the core - arguments
advantages/disadvantages of both schemas.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
> (just added)

  Thank you. Maybe it is better to discuss here before adding to wiki?
  My arguments on the points you've added:

  1. Regarding benefit of having a combining level/tag natural=water.
If today you would query all data with natural=water - you will get
not only lakes and reservoirs grouped, but also riverbank polygons
(totally different beast) and micro elements like water=pond. This
could only be partly useful in the largest scale maps and only if you
make very simple maps and for some reason use the same symbolisation
for such different water classes. For example ponds usually have less
complex and less prominent symbolisation because of their size and
importance. Riverbanks would not need polygon labelling, but rather
use river (central) line for label placement. Most of GIS/Cartography
work goes in middle/small scales and it will be impossible to use only
natural=water there, you would have to add "and water not in
('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
makes it of the same complexity from coding perspective as original
water scheme.

  2. Very important disadvantage of water=reservoir from
cartographic/gis perspective: it allows mappers to NOT differentiate
between natural lakes and man made reservoirs. If first point
describes how different classes are USED, this second point is about
how these classes are CAPTURED.

  Did I miss anything?

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging



Dec 16, 2020, 14:42 by tomasstrau...@gmail.com:

>> I get that you consider benefits of natural=water water=* schema
>> as unimportant
>>
>
> Can you LIST the benefits? As you see them TODAY. So that we could
> evaluate/compare?
>  (Not point to proposal on wiki, as largest part of it never materialised)
>

https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
(just added)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Brian M. Sperlongano
Tomas,

Since you are not willing to accept (1) an existing approved proposal, (2)
new proposal to correct flaws in the first one, or (3) the overwhelming
preference of the mapping community over the past four years[1], then I'm
sorry but we must curtly dismiss your arguments as a one-man crusade[2,3,4]
against tagging which you do not like.  It is clear that you wish to impose
your views on the community regardless of what the consensus is.  If there
is truly a community of mappers out there that share your view, it should
be easy to convince them to come and vote.  Since you are not willing to
accept the democratic process that we have established, and you do not
respect the viewpoints of others, all you are doing is wasting our time.
Thus I ask you, respectfully, to stop.

If there are others here that desire a proposal for the purpose of
documenting that landuse=reservoir is deprecated, I will gladly do so.
With no proposal, the status quo will remain: landuse=reservoir will
continue to be steadily replaced with water=reservoir, and our wiki will
remain confusing in its documentation of these tags.

[1] https://wiki.openstreetmap.org/wiki/User:ZeLonewolf/Analysis/Reservoir
[2] https://github.com/openstreetmap/iD/issues/7382
[3] https://github.com/openstreetmap/iD/issues/6589
[4] https://josm.openstreetmap.de/ticket/17874


On Wed, Dec 16, 2020 at 8:32 AM Tomas Straupis 
wrote:

> > If you believe that your argument in favor of tagging reservoirs as
> landuse is
> > strong, then you should have no objection to placing this question up
> for a
> > community vote, and allowing the community the freedom to decide.
>
>   Brian, landuse=reservoir is the ORIGINAL and ACTIVE schema. Why
> should anybody propose the vote for it?
>
>   I do not like voting on wiki because it is clearly a flawed process
> (as discusses a number of times), what do 20 wiki participants/people
> mean against the actual mappers? We could end up in the same situation
> as with original water=reservoir proposal where somebody with barely
> few months of participation in OSM and no knowledge of GIS/Carto
> makes/influences the decision/proposal...
>
>   And what is a problem of listing benefits of water=reservoir schema?
> If there are none, then the only logical decision is to deprecate
> water=reservoir, because it would make it worse of the two. Shouldn't
> we get ARGUMENTS before we go to any kind of voting/decision?
>
> ___
> 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] How to tag entire group of rentable holiday cottages?

2020-12-16 Thread Martin Koppenhoefer


sent from a phone

> On 16. Dec 2020, at 14:44, Martin Koppenhoefer  wrote:
> 
> https://huettenpalast.de/


meant to post this 
https://hostelgeeks.com/wp-content/uploads/2019/08/hafentraum-indoorcampinghostel-best-hostels-in-germany.jpg

Cheers Martin 

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


Re: [Tagging] How to tag entire group of rentable holiday cottages?

2020-12-16 Thread Martin Koppenhoefer


sent from a phone

> On 16. Dec 2020, at 04:07, Graeme Fitzpatrick  wrote:
> 
> Individual as 1 cabin per site, or, as Mateusz raised, multiple cabins on one 
> site?


even multiple cabins in one building 
https://huettenpalast.de/
#nothreadwithoutanedgecase
;-)

Cheers Martin 

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
> I get that you consider benefits of natural=water water=* schema
> as unimportant

  Can you LIST the benefits? As you see them TODAY. So that we could
evaluate/compare?
  (Not point to proposal on wiki, as largest part of it never materialised)

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging



Dec 16, 2020, 14:29 by tomasstrau...@gmail.com:

>  And what is a problem of listing benefits of water=reservoir schema?
> If there are none
>
I get that you consider benefits of natural=water water=* schema
as unimportant

But, please, stop pretending that there are no benefits. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
> If you believe that your argument in favor of tagging reservoirs as landuse is
> strong, then you should have no objection to placing this question up for a
> community vote, and allowing the community the freedom to decide.

  Brian, landuse=reservoir is the ORIGINAL and ACTIVE schema. Why
should anybody propose the vote for it?

  I do not like voting on wiki because it is clearly a flawed process
(as discusses a number of times), what do 20 wiki participants/people
mean against the actual mappers? We could end up in the same situation
as with original water=reservoir proposal where somebody with barely
few months of participation in OSM and no knowledge of GIS/Carto
makes/influences the decision/proposal...

  And what is a problem of listing benefits of water=reservoir schema?
If there are none, then the only logical decision is to deprecate
water=reservoir, because it would make it worse of the two. Shouldn't
we get ARGUMENTS before we go to any kind of voting/decision?

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


Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Skyler Hawthorne


On Wed, Dec 16, 2020, at 05:44, Tom Pfeifer wrote:

Trying to understand your question, the way in your example is tagged:


destination Troy

destination:ref I 787 North


From the data consumer perspective, such tagging will generate a navigation 
instruction:


"turn slightly right towards Troy, I 787 North". This would be helpful as 
long as the driver


is able to recognise it on the local signposting.


What is written on the sign at this junction? If "North" is mentioned there 
I would be


happy enough with the tagging above.


That is correct, the sign says "I 787 North". However the wiki page for the 
destination:ref key states:


The key destination:ref=* should be used to specify the reference of the 
roads directly ahead as indicated on signposts, road markings or similar. 
The value of this key should be equal to the value of the key ref=* of 
these roads.
Note the last sentence. If the destination:ref must be the same as the ref 
it is going to, then this would be I 787, or else all the ways along the 
entire I 787 route should have their ref tags changed to indicate direction 
as well.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Brian M. Sperlongano
Tomas,

If you believe that your argument in favor of tagging reservoirs as landuse
is strong, then you should have no objection to placing this question up
for a community vote, and allowing the community the freedom to decide.


On Wed, Dec 16, 2020 at 8:01 AM Tomas Straupis 
wrote:

> 2020-12-16, tr, 01:32 Brian M. Sperlongano rašė:
> > The iD editor preset appears to use water=reservoir while the JOSM
> > preset appears to use landuse=reservoir.
>
>   Not entirely correct.
>   * JOSM gives freedom to mappers and supports BOTH.
>   * iD forces to use water=reservoir and evenmore pushes users to
> change tagging by disguise of "upgrade" - therefore even mappers who
> do not understand/know the difference are inclined to change the
> tagging. <- this is the reason for current stats
>
>   My understanding is that given landuse=reservoir is the original
> water schema, the new one should show some benefits to replace the
> original one? Or we do not care about consistency and simply go on
> with replacing very prominent schemas for no good reason?
>
>   My take is that:
>   * landuse=reservoir is better compared to natural=water+water=x
> because it pushes mappers to make distinction for these
> GIS/Cartographically very different classes of water. Therefore if
> landuse=reservoir is deprecated tagging will be worse.
>
>   What are the benefits of water=reservoir?
>   Given that full scope of proposal to put all water classes under
> natural=water (the purpose which is disadvantageous from
> GIS/Cartography perspective) have failed and we're now only talking
> about two classes of water (natural and man made), and classes which
> are very different and therefore should not be merged.
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 01:32 Brian M. Sperlongano rašė:
> The iD editor preset appears to use water=reservoir while the JOSM
> preset appears to use landuse=reservoir.

  Not entirely correct.
  * JOSM gives freedom to mappers and supports BOTH.
  * iD forces to use water=reservoir and evenmore pushes users to
change tagging by disguise of "upgrade" - therefore even mappers who
do not understand/know the difference are inclined to change the
tagging. <- this is the reason for current stats

  My understanding is that given landuse=reservoir is the original
water schema, the new one should show some benefits to replace the
original one? Or we do not care about consistency and simply go on
with replacing very prominent schemas for no good reason?

  My take is that:
  * landuse=reservoir is better compared to natural=water+water=x
because it pushes mappers to make distinction for these
GIS/Cartographically very different classes of water. Therefore if
landuse=reservoir is deprecated tagging will be worse.

  What are the benefits of water=reservoir?
  Given that full scope of proposal to put all water classes under
natural=water (the purpose which is disadvantageous from
GIS/Cartography perspective) have failed and we're now only talking
about two classes of water (natural and man made), and classes which
are very different and therefore should not be merged.

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


Re: [Tagging] How to tag entire group of rentable holiday cottages?

2020-12-16 Thread Paul Allen
On Wed, 16 Dec 2020 at 03:07, Graeme Fitzpatrick 
wrote:

>
> On Tue, 15 Dec 2020 at 23:55, Paul Allen  wrote:
>
>>
>> 1) Holiday cottages are rarely building=cabin, they are mostly
>> building=house.
>>
>
> May depend on where you are? I know of a number of places that advertise
> cottages / cabins eg http://lyrebirdspringbrook.com/index.html
>

Cabins as holiday cottages may be common in your part of the world but
in my part they're rare.  This is a holiday cottage around the corner
from me: http://maenayron.co.uk/accomodation/  And these are
a group of six holiday cottages in converted farm buildings:
https://www.trenewydd.com/

One around the corner from me is a former house
>> that has been converted to a holiday let.  Even the ones on farms
>> are converted stone barns, converted stone stables, etc.
>>
>
> Shouldn't they then stay as their original type of building? From the
> buildings page:  the value may be used to classify the type of building.
> Note that it may be not the same as the building's current use (tagged
> using building:use 
> =*). For example, a hospital building that is abandoned or repurposed to
> be a marketplace is still a building=hospital
> 
>

Indeed.  building=house + tourism=chalet or building=barn + tourism=chalet
or building=cabin + tourism=chalet, depending on the original building type.

>
>
>> 2) A farm which has converted some of its buildings to
>> holiday cottages will have a mix of building types.  Mappers
>> who wish to go into details would prefer to see the
>> individual holiday cottages rendered distinctly (as
>> they currently are).
>>
>
> But building=yes + name=xxx will still render sufficiently, won't it?
>

Apart from the icon.  Which, if you're looking at a map of the area looking
for places to stay is kinda important.  Just building and name is
indistinguishable from any other building with a name.  See
https://www.openstreetmap.org/?mlat=52.08485=-4.65761#map=18/52.08485/-4.65761

>
> 3) This scheme has problems with individual holiiday
>> cottages, such as the one around the corner from me,
>> unless you retain tourism=chalet for such cases.
>>
>
> Individual as 1 cabin per site, or, as Mateusz raised, multiple cabins on
> one site?
>

Individual as 1 cabin per site.  As in a working farm that has converted
just
one of its outbuildings to a holiday cottage.  As in an ordinary house in a
row of houses that is operated as a holiday cottage.

I can understand some mappers may not want to add multiple holiday
cottages on a single site and want a short cut.  I'm happy with that
as long as it doesn't preclude adding them as individual cottages later.
Some sort of grouping tag is desirable for searchability using
Nominatim.  Some sort of grouping tag is desirable for rendering.
But I'd like to be able to present a usable representation of a
site with multiple holiday cottages so that consumers can tell
what is and isn't a holiday cottage without having to cross-refer
with a website or facebook page.  Such as here
https://www.openstreetmap.org/#map=19/52.10789/-4.61545

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


Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Tom Pfeifer

Trying to understand your question, the way in your example is tagged:

destination Troy
destination:ref I 787 North

From the data consumer perspective, such tagging will generate a navigation 
instruction:
"turn slightly right towards Troy, I 787 North". This would be helpful as long 
as the driver
is able to recognise it on the local signposting.

What is written on the sign at this junction? If "North" is mentioned there I 
would be
happy enough with the tagging above.

I have seen the compass direction quite often signposted on major roads in the 
US,
thus the question boils down if it is considered to be part of the 'ref'.
A general tag for the compass direction is 'direction', which is used 79% (shy 
of 1 mill
times) on highways.

So for the interstate itself, splitting it into ref=I 787 and direction=N would 
be preferable.

tom

On 16.12.2020 04:40, Skyler Hawthorne wrote:
I've seen a few examples in both New York and California put in the tags of on-ramps the 
destination:ref that has the direction in it, e.g.: https://www.openstreetmap.org/way/5566969


However, after looking through the wiki, to my surprise, I cannot find this practice mentioned 
anywhere. It made sense to me when I saw it because how else is GPS navigation supposed to tell you 
which highway to get onto? But I don't see it mentioned anywhere, and in fact, the only thing the 
wiki page on Highway Directions in the United States mentions is putting the direction on the ways 
of the actual freeway.


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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Mateusz Konieczny via Tagging

Dec 16, 2020, 00:17 by zelonew...@gmail.com:

> 1. It is not clear from the original 2011 vote which created water=reservoir 
> (and other values) as to whether the community intended to deprecate 
> landuse=reservoir or whether the community intended to create two parallel 
> tagging schemes for the same object.
>
To be more specific...

https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Water_details=633881#Deprecation

""Deprecates" means "is equivalent for all purposes to". For example, landuse 
=reservoir 
 
should be rendered exactly like natural 
=water 
 + water 
=reservoir. There are too many 
uses of the current tagging scheme, and we don't want massive retagging and 
edit wars."

So it was titled as deprecation, redefined deprecation to mean something else 
and
claimed that retagging is not wanted.

Great :(

> Given these issues, I would suggest a narrowly-written proposal that puts 
> forth the clear and specific question as to whether landuse=reservoir should 
> be deprecated.  If that proposal demonstrates clear community consensus for 
> deprecation (per the guidelines in our proposal process), we can update our 
> wiki documentation to explicitly recommend that landuse=reservoir be 
> gradually replaced by natural=water+water=reservoir.  If, instead, that 
> proposal demonstrates that there is still a sizable subset of mappers that 
> prefer the landuse=reservoir tag, we would simply leave both tags documented 
> without caveats, noting the results of both this and the 2011 proposals, and 
> allow the community to sort out which tagging scheme is preferred based on 
> actual usage over time.
>
> As I am the one that raised this issue in the first place, I would be happy 
> to draft such a proposal for consideration.  I want to be clear that in such 
> a proposal, any instances of disrespectful or insulting commentary directed 
> towards any group or individual will not be tolerated and will be immediately 
> brought to the attention of the wiki admins for followup.
>
> Would this be satisfactory to the group in resolving the question of 
> reservoir tagging?
>
Yes, though note that it is likely to just reconfirm stalemate.

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-16 Thread Jeremy Harris

On 16/12/2020 08:41, Ture Pålsson via Tagging wrote:

 Maybe it would be better to use a convex
hull...

and then polylabel, and then have all the labels repel each other
while being attracted to that point?

Preferably this springy attract/repel should account for the
text outline rather than the text centre-point.
--
Cheers,
  Jeremy

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-16 Thread Ture Pålsson via Tagging

2020-12-15 08:48  Anders Torger a écrit:


However I'll soon go through these edits again and then I will add multipolygon 
for the split, and if your renderer takes that into account we should end up 
with a single multipolygon. I think in the case of Muddus it will work in all 
cases, ie we won't hit the corner case described above which should be very 
rare. So I think this naming concept is okay as a stepping stone until we can 
move forward on this issue. I hope we can make a point though that this is not 
a acceptable as a long-term solution.


I'm drifting away from tagging into renderer implementation territory
now, but this thread is large anyway, so what the heck... :-) 


Your last edits actually caused some headaches for my renderer, because
you added in some "satellite" bits of bog that were not (I think)
previously included. The renderer insists on putting a label on each
disjoint area, so I ended up with a handful of them. 


So I resorted to the old "buffer and join" hack, adding a 100-meter
buffer around each area and ST_Union:ing the result (isn't it fun when
you realize you have all the plumbing in place and can do new things by
just adding a few lines of code?). Now the map looks like this:
http://lab3.turepalsson.se/~ture/rijmmoahpe-20201216.pdf . The red
outlines show the areas that the renderer is actually considering when
placing the labels. 


The label placement for Aleldusáhpe near the top of the map looks...
less than ideal. I suspect that this is because I use (an implementation
of) the Mapbox polylabel [1] algorithm, and it gets derailed by the
small holes inside the areas. Maybe it would be better to use a convex
hull... or just a bigger buffer. Label placement is a black art... 


Links:
--
[1] https://github.com/mapbox/polylabel___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging