Re: [Tagging] Deprecate water=pond?

[Joseph Eisenberg]

Re: "I can hardly think of any waterbody, intermediate on the large..small
and natural..artificial scales between the Great Lakes and a farmer's stock
pond, where the `water=*` value would be uncontroversial."

water=canal is the consensus tag for the area of a canal. There was never a
standard way to tag this before, so I would strongly recommend adding this
tag for all canals when mapped as an area with natural=water. Similarly,
water=lock is uncontroversial and widely used.

While there is still some controversy about using water=river +
natural=water instead of waterway=riverbank for the area of a river, it is
uncontroversial that you should certainly add  water=river if you are using
natural=water in this case.

The same thing goes for reservoirs and basins: you can also use
landuse=basin or landuse=reservoir, but if you map them with natural=water
it is very helpful to use water=basin or water=reservoir

Those values account for most of the uses of water=*... except for
water=pond, which is where we started.

On Fri, Nov 13, 2020 at 7:05 PM Kevin Kenny  wrote:

> On Thu, Nov 12, 2020 at 6:22 PM Adam Franco  wrote:
>
>>
>>- origination:natural=beavers
>>
>> Thanks for remembering this one. Around here, beavers are a significant
> sculpting force on the landscape.
>
> (And `man_made=dam` is the best tagging that we have for their water
> control structures, which are also often adjusted seasonally)
>
> Very long story short, I think we might be able to worry a little less
>> about what the body of still water *is* and more about its other
>> properties that might be of interest. In programming languages this is
>> referred to as "duck typing ".
>>
>
> If ducks could type, I could easily imagine that a pond might be mapped
> and the tags entered by a duck typing. I think that the duck in question
> might be Atwood's Duck.
> https://en.wikipedia.org/wiki/Law_of_triviality#Related_principles_and_formulations
>
> And ... having seen this argument several times before, I basically avoid
> `water=*` when mapping. I can hardly think of any waterbody, intermediate
> on the large..small and natural..artificial scales between the Great Lakes
> and a farmer's stock pond, where the `water=*` value would be
> uncontroversial. `natural=water` renders, and I'll try to avoid taking a
> census of the angels dancing on that particular pinhead.
>
> This whole discussion reminds me of one time that someone who wasn't from
> around here (nor a native speaker) was insisting that anything that was
> called a 'creek' in English *must* be a tiny watercourse.  Not around here!
> The creek in question was, if memory serves, either the Schoharie Creek,
> shown in this picture:
> http://minerva.union.edu/garverj/mohawk/images/schoharie_falls.jpg or
> else the West Canada Creek
> https://en.wikipedia.org/wiki/West_Canada_Creek#/media/File:Aug_2011_Ft_Noble_Mtn.JPG
> I'm comfortable with `waterway=river` on any waterway where I map the
> riverbank.
>
> On Thu, Nov 12, 2020 at 2:52 PM Paul Allen  wrote:
>>
>>> On Thu, 12 Nov 2020 at 19:30, Joseph Eisenberg <
>>> joseph.eisenb...@gmail.com> wrote:
>>>
 Re: is water=* tag needed?

>>>
>>>
 But since water=pond is not clearly defined as natura/semi-natural vs
 man-made, we have a large number of features where the water=* tag is not
 providing this information. Since the previous tagging system clearly
 distinguished natural from man-made water bodies, this would be a loss for
 database quality.

>>>
>>> We often do not know if it is natural or artificial.  Maybe it's a
>>> natural
>>> depression in the ground that fills with water.  Maybe it was created
>>> by man as a water feature.  Maybe it's an old quarry that has flooded.
>>> Even if it was originally a result of something like quarrying it may
>>> have
>>> happened so long ago that there are no records.
>>>
>>> What we can determine (at least in principle) is if it meets criteria
>>> for a lake (large size or large waves or has aphotic zones) or a
>>> pond.  In principle, a suitably-qualified mapper could investigate
>>> those things on site.  We can accept using guesswork based on
>>> size pending fuller investigation. A lake/pond distinction is
>>> useful irrespective of whether it is entirely natural or entirely
>>> artificial.
>>>
>>> Determining if it's entirely natural, or deliberately man-made, or
>>> an unintended consequence of past human activity is harder.
>>> Possible for retention basins that are still in use.  Mostly
>>> possible for reservoirs, although some reservoirs are
>>> based around natural lakes.  But historical records are
>>> incomplete (and some mappers insist we should never
>>> ever make use of historical data to inform our mapping).
>>>
>>> Maybe we need an artificial=yes/no.
>>>
>>> --
>>> Paul
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.o

Re: [Tagging] Deprecate water=pond?

[Kevin Kenny]

On Thu, Nov 12, 2020 at 6:22 PM Adam Franco  wrote:

>
>- origination:natural=beavers
>
> Thanks for remembering this one. Around here, beavers are a significant
sculpting force on the landscape.

(And `man_made=dam` is the best tagging that we have for their water
control structures, which are also often adjusted seasonally)

Very long story short, I think we might be able to worry a little less
> about what the body of still water *is* and more about its other
> properties that might be of interest. In programming languages this is
> referred to as "duck typing ".
>

If ducks could type, I could easily imagine that a pond might be mapped and
the tags entered by a duck typing. I think that the duck in question might
be Atwood's Duck.
https://en.wikipedia.org/wiki/Law_of_triviality#Related_principles_and_formulations

And ... having seen this argument several times before, I basically avoid
`water=*` when mapping. I can hardly think of any waterbody, intermediate
on the large..small and natural..artificial scales between the Great Lakes
and a farmer's stock pond, where the `water=*` value would be
uncontroversial. `natural=water` renders, and I'll try to avoid taking a
census of the angels dancing on that particular pinhead.

This whole discussion reminds me of one time that someone who wasn't from
around here (nor a native speaker) was insisting that anything that was
called a 'creek' in English *must* be a tiny watercourse.  Not around here!
The creek in question was, if memory serves, either the Schoharie Creek,
shown in this picture:
http://minerva.union.edu/garverj/mohawk/images/schoharie_falls.jpg or else
the West Canada Creek
https://en.wikipedia.org/wiki/West_Canada_Creek#/media/File:Aug_2011_Ft_Noble_Mtn.JPG
I'm comfortable with `waterway=river` on any waterway where I map the
riverbank.

On Thu, Nov 12, 2020 at 2:52 PM Paul Allen  wrote:
>
>> On Thu, 12 Nov 2020 at 19:30, Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> Re: is water=* tag needed?
>>>
>>
>>
>>> But since water=pond is not clearly defined as natura/semi-natural vs
>>> man-made, we have a large number of features where the water=* tag is not
>>> providing this information. Since the previous tagging system clearly
>>> distinguished natural from man-made water bodies, this would be a loss for
>>> database quality.
>>>
>>
>> We often do not know if it is natural or artificial.  Maybe it's a natural
>> depression in the ground that fills with water.  Maybe it was created
>> by man as a water feature.  Maybe it's an old quarry that has flooded.
>> Even if it was originally a result of something like quarrying it may have
>> happened so long ago that there are no records.
>>
>> What we can determine (at least in principle) is if it meets criteria
>> for a lake (large size or large waves or has aphotic zones) or a
>> pond.  In principle, a suitably-qualified mapper could investigate
>> those things on site.  We can accept using guesswork based on
>> size pending fuller investigation. A lake/pond distinction is
>> useful irrespective of whether it is entirely natural or entirely
>> artificial.
>>
>> Determining if it's entirely natural, or deliberately man-made, or
>> an unintended consequence of past human activity is harder.
>> Possible for retention basins that are still in use.  Mostly
>> possible for reservoirs, although some reservoirs are
>> based around natural lakes.  But historical records are
>> incomplete (and some mappers insist we should never
>> ever make use of historical data to inform our mapping).
>>
>> Maybe we need an artificial=yes/no.
>>
>> --
>> Paul
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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

[Tagging] Questions about public transport tagging

[ipswichmapper--- via Tagging]

Hello, I have quite a few questions about Public Transport related tagging in 
Openstreetmap.

My first question is about the "interval:conditional" & "opening_hours" tag for 
bus routes. The "Bus Route" page on the OSM wiki mentions this tag, but the 
train route or "public transport" route page does not mention this tag at all. 
So I wanted to ask, is this tag discouraged?

The disadvantage of this tag, obviously, is that it is quite difficult to 
maintain. However, I think it is possible. My method would be to make a table 
which contains all the public transport route relations in an area, and add a 
column for "last checked". This would display the last date that this public 
transport route was checked. Regular mappers can do a check of a bunch of 
public transport routes every few months to see if the opening_hours or 
interval:conditional has changed. (I plan on including this on a guide to 
mapping public transport routes that I will be making).

Here is the table for Ipswich:

https://wiki.openstreetmap.org/wiki/Ipswich#Public_Transport_Version_2

Note currently, this is not formatted how I described. The reason for this is 
because not every bus routes has been added, so instead of having a "last 
checked" column, there are four columns ("interval", "interval:conditional", 
"duration", "opening_hours"). This is because some of the unfinished routes 
still don't have these tags.

Second question is about mapping train route stops. If I understand correctly, 
you are meant to add the platform at which people wait with role "platform" as 
well as the stop position of the train with role "stop".

I see issue with this. Firstly, none of this is clarified on the wiki under 
train routes. Secondly, what if you don't know what platform the train will 
leave from? What if there is no platform? In the UK this isn't a problem as all 
train stations have platforms. However, in other countries, in rural areas, 
train stations may not have any built up platform, you just wait by the side of 
the railway.

Secondly, why do you have to map stops and not platforms? Again, if the train 
goes at different platforms, then the stop position will also be different. You 
may not know what the stop position is, in which case you chose a random point 
on the railroad. Instead, it would be much better if you could just mark the 
"station" as a member of the relation. However, there is no "station" role, so 
adding a station creates a role verification problem.

Last question is about "combining intervals". This is something that, if 
needed, can be asked about in another thread (as it needs more discussion). In 
many cases, multiple bus routes go down the same path for a significant section 
of their journey, and split near the end of their journey.  An example of this 
is route 66 & route 66A in Ipswich. [1][2][3]

For most of their journey, these buses have the same route. Combined, their 
interval is "every 20 minutes". The interval of 66A is every hour. The 66 has a 
20 minute interval, then a 40 minute one, then a 20 min one, etc.

If these were mapped separately, you a routing software wouldn't be able to 
compute that the interval is 20 minutes. So how can this be fixed?

The solution I can think of is to map a separate relation called ("66/66A") 
which is the combined route and give it a interval of 20 minutes. However, I'm 
pretty sure some tags would be needed to be made for this, because otherwise it 
breaks the ground rule (as there is no bus called "66/66A" in real life). 

Another interesting idea was suggested in this Reddit post:

https://old.reddit.com/r/openstreetmap/comments/jkdsjr/common_area_of_bus_routes/

That is that roads with multiple bus routes can be tagged with the bus route, 
instead of the other way route (to cut down on repetition).
Thanks,

IpswichMapper

[1]: https://www.openstreetmap.org/relation/190701
[2]: https://www.openstreetmap.org/relation/9984463
[3]: 
https://www.firstgroup.com/uploads/maps/FEC-Ipswich%20Reds%2066%20-%20Bus%20Times%20from%2025-10-20.pdf


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

Re: [Tagging] Deprecate water=pond?

[Peter Elderson]

Ah, profiling! Hadn't thought of that yet.

Best, Peter Elderson


Op vr 13 nov. 2020 om 10:18 schreef Michael Patrick :

>
> I am surprised nobody has suggested a pondness or lakicity scale yet.
>>
>
> It isn't unusual outside of OSM for relative percentages of the different
> meanings to be accounted for. For example for Great Pond (
> https://www.topoquest.com/map.php?lat=44.5&lon=-69.8&datum=nad83&zoom=16
> ) with a surface area of 13 square miles
>
> lake 15%
> reservoir 84%   ( volume added to the original lake by the dam )
> pond 1%
>
>
>
> <#m_2101975028351855335_m_-6680278241776399936_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] Deprecate water=pond?

[Michael Patrick]

> I am surprised nobody has suggested a pondness or lakicity scale yet.
>

It isn't unusual outside of OSM for relative percentages of the different
meanings to be accounted for. For example for Great Pond (
https://www.topoquest.com/map.php?lat=44.5&lon=-69.8&datum=nad83&zoom=16
) with a surface area of 13 square miles

lake 15%
reservoir 84%   ( volume added to the original lake by the dam )
pond 1%


<#m_-6680278241776399936_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging