[Tagging] Feature Proposal - Voting - training=bicycle

2020-11-12 Thread Mathieu
https://wiki.openstreetmap.org/wiki/Proposed_features/training%3Dbicycle

To describe the bicycle lessons often provided by shops or other bicycle
related places
This attribute could be applied to different kinds of POIs : an NGO or
public administration could provide such lessons
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread Adam Franco
I'm wondering if rather than deprecating water=pond, it would be better to
keep it as a value with overlapping usage to lake (like river/stream) and
instead focus tagging on the actual differences between different bodies of
water.

I'd suggest two new tags that get at the heart of what I've been hearing
people suggesting as distinctions between all these water-bodies other than
size, their origin (natural or human-made) and whether they are naturally
flowing at their outlets, have human-created outlet controls, or no outlet
(in the case of endorheic basins
 or some quarries):

   - origination=natural/artificial
   - outlet_control=natural/artificial/no-outlet

*(I wanted to use "origin", but that is currently used for goods from
shops.)*

These could of course be sub-tagged if desired to add more specificity.
Examples:

   - origination:natural=glaciation
   - origination:natural=landslide (if a natural dam was formed by a
   landslide)
   - origination:natural=beavers
   - origination:artificial=quarry
   - outlet_control:natural=bedrock
   - outlet_control:natural=soil
   - outlet_control:natural=beavers

Here are a few examples of lakes, ponds, and reservoirs that I'm familiar
with that seem useful for this discussion:

*Abbey Pond, Middlebury, Vermont*: OSM
,
photo 
This pond appears to have been scoured out during the last glaciation
period and drains over a hard-rock ledge. It appears to not be very deep,
but the presence of the ledge ensures that this pond will exist until
silted in or the land is re-formed by glaciers. At the same time, beaver
activity just upstream of the rock-ledge has raised the water level by 1-2
meters. This I would tag as:

   - water=pond
   - origination=natural
   - origination:natural=glaciation
   - outlet_control=natural
   - outlet_control:natural=beavers

*Crystal Lake, Beulah, Michigan:* OSM
, photo
, outlet dam photo

This large 3-mile x 9-mile lake was scoured out alongside Lake Michigan
during the last glaciation period. It's origin is very natural. It's water
level sat about 43 feet higher than Lake Michigan until 1873 when an
attempt at digging a transportation canal spectacularly failed dropped the
lake level by about 20'. (source 1
,
source
2
).
Today the lake-level is controlled by an artificial outlet dam

(really a weir) with its level changed seasonally. While this is by every
definition a naturally formed lake, it is today controlled by humans.

   - water=lake
   - origination=natural
   - origination:natural=glaciation
   - outlet_control=artificial
   - outlet_control:artificial=weir

A decorative human-made pond that empties over a rocky berm with no
operable level-control structures might be tagged with

   - water=pond
   - origination=artificial
   - outlet_control=natural

A totally natural lake with no human intervention might be:

   - water=lake
   - origination=natural
   - outlet_control=natural
   - outlet_control:natural=bedrock

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


On Thu, Nov 12, 2020 at 2:52 PM Paul Allen  wrote:

> On Thu, 12 Nov 2020 at 19:30, Joseph Eisenberg 
> 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
> 

Re: [Tagging] Feature proposal - RFC - Place of mourning (replacing "Chapel of rest")

2020-11-12 Thread Martin Koppenhoefer


sent from a phone

> On 12. Nov 2020, at 21:10, Joseph Eisenberg  
> wrote:
> 
> You need to explain this on the new proposal page. Note that on 
> Tag:shop=funeral_directors it says "an event (sometimes with the deceased's 
> body present) to honor the deceased for mourners are held here in conjunction 
> with religious services which are held elsewhere."


I find it irritating that funeral directors is described as a place where the 
body might be stored and a cerimony is held, certainly not something I have 
heard of in Germany or Italy. Admittedly this is already there for a long time, 
but from my understanding the former definition was much clearer:

https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ashop%3Dfuneral_directors=revision=832146=689750


Cheers Martin 


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


Re: [Tagging] How to tag a threshing floor

2020-11-12 Thread António Madeira via Tagging

Thank you, Joseph.

If no one opposes, I'll do just that.
Regards.


Às 16:43 de 12/11/2020, Joseph Eisenberg escreveu:

Since the tag man_made=threshing_floor has already been used 7 times
(https://taginfo.openstreetmap.org/search?q=threshing_floor#values)
you can create a page to document this, however, you would also need
to mention that historic=threshing_floor is much more common (actually
landuse=threshing_floor is also equally common), and it would probably
be fair to create a historic=threshing_floor wiki page too, in that case.

If you want to suggest deprecating historic=threshing_floor and
replacing it with man_made=threshing_floor, or otherwise changing
existing common usage, you should make a proposal so that the
community can discuss this.

-- Joseph Eisenberg

On Wed, Nov 11, 2020 at 2:53 PM António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

So, given that most of those who commented this thread agreed that
threshing_floor should be in the man_made scheme, should I add it
to the wiki or create a Feature Proposal?


Às 19:27 de 06/11/2020, Paul Allen escreveu:

On Fri, 6 Nov 2020 at 21:53, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:

Am Fr., 6. Nov. 2020 um 13:56 Uhr schrieb Paul Allen
mailto:pla16...@gmail.com>>:

On Fri, 6 Nov 2020 at 09:09, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>>
wrote:

...

To me it doesn't make sense to draw a line, dividing
the same objects having more or less historic value.
If there is something to distinguish at all, my
suggestion would be to add a qualifier to those
objects of exceptional historical value (if this is
verifiable).


We have a way of tagging objects of exceptional
historical value, it's
historic=*.  Objects of unexceptional historical value,
or of no historical
value do not get tagged with historic=*. That's because
historic is
not a synonym (in the real world or in tagging) for old,
disused or
repurposed.


just that it is not what we are currently doing.

That is not what some of us are currently doing. Others read the
wiki page
and tag accordingly.

It occurs to me that some of the mis-tagging (as I see it) and
some of the
discussions here may revolve around semantics as interpreted by
those who do not have English as a first language.  There is a
difference between "historical" and "historic."

Historians are concerned with historical data. Old data (about
populations, diseases or whatever) is historical data.  The
assassination of a minor archduke, which seemed unimportant
at the time, quickly turned into a historic event.

When somebody says that "historic" applies to everything that
historians do, that is incorrect.  What historians mostly do is
look at historical data, some small fraction of which is
also historic.

See https://www.grammarly.com/blog/historic-historical/
for a better explanation.

So historic=* really should only apply (as the wiki page states)
to the important
things of the past, not everything some random historian might happen
to be looking into.

So the question is, do we accept that because some mappers have
misused
the tag we should encourage that misuse or do we discourage it?

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


___
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] Feature proposal - RFC - Place of mourning (replacing "Chapel of rest")

2020-11-12 Thread Joseph Eisenberg
See comments on the last proposal:

"*It is redundant. I really don't understand why we need another tag for a
room or building where families and friends can come and view someone who
has died before their funeral. The tag shop=funeral_directors fits
perfectly the definition of this new tag proposal (please read it) I quote
the definition for funeral_directors: "An event (a place) to honor the
deceased for mourners are held here in conjunction with religious services
which are held elsewhere". And the tag amenity=funeral_hall can be used
instead, in the case that religious ceremonies (any creed) are allowed in
the building. Funeral Halls in many countries (as mine [México]) help
mourners with all the administrative documentation as Funeral Directors do.
If we want to have a tag for every possible difference in all countries we
will have a myriad of tags and a complete confussion on which tag to use.*"

*"I note that the English Wikipedia page Funeral_home directs to Funérarium
in French, which is the term described in the lede. Similarly, I am also
having trouble understanding where the distinction is between the two."*

*"my Oxford defines "chapel of rest" as "an undertaker's mortuary, where
bodies are kept before a funeral" and does not reflect on the visitation
aspect at all"*

You need to explain this on the new proposal page. Note that on
Tag:shop=funeral_directors
 it says *"an
event (sometimes with the deceased's body present) to honor the deceased
for mourners are held here in conjunction with religious services which are
held elsewhere."* Also Tag:amenity=mortuary
 says "A morgue
or funeral home" which might include a place for a viewing. --Jeisenbe
(talk
) 20:05, 12
November 2020 (UTC)

On Wed, Nov 11, 2020 at 11:08 AM  wrote:

> Dear all,
>
> As already discussed, "place of mourning" seems to be a less bad label
> than "chapel of rest".
>
> Therefore please comment on the following new proposal:
>
> Place of mourning: a room or building where families and friends can
> come and view someone who has died, before their funeral
>
> Proposal page:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Place_of_mourning
> Discussion page:
>
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Place_of_mourning
>
> Thanks!
>
> Vollis
>
> ___
> 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?

2020-11-12 Thread Paul Allen
On Thu, 12 Nov 2020 at 19:30, Joseph Eisenberg 
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


Re: [Tagging] How to tag a threshing floor

2020-11-12 Thread Joseph Eisenberg
Since the tag man_made=threshing_floor has already been used 7 times (
https://taginfo.openstreetmap.org/search?q=threshing_floor#values) you can
create a page to document this, however, you would also need to mention
that historic=threshing_floor is much more common (actually
landuse=threshing_floor is also equally common), and it would probably be
fair to create a historic=threshing_floor wiki page too, in that case.

If you want to suggest deprecating historic=threshing_floor and replacing
it with man_made=threshing_floor, or otherwise changing existing common
usage, you should make a proposal so that the community can discuss this.

-- Joseph Eisenberg

On Wed, Nov 11, 2020 at 2:53 PM António Madeira via Tagging <
tagging@openstreetmap.org> wrote:

> So, given that most of those who commented this thread agreed that
> threshing_floor should be in the man_made scheme, should I add it to the
> wiki or create a Feature Proposal?
>
>
> Às 19:27 de 06/11/2020, Paul Allen escreveu:
>
> On Fri, 6 Nov 2020 at 21:53, Martin Koppenhoefer 
> wrote:
>
>> Am Fr., 6. Nov. 2020 um 13:56 Uhr schrieb Paul Allen > >:
>>
>>> On Fri, 6 Nov 2020 at 09:09, Martin Koppenhoefer 
>>> wrote:
>>>
>>> ...
>>>
>>> To me it doesn't make sense to draw a line, dividing the same objects
 having more or less historic value. If there is something to distinguish at
 all, my suggestion would be to add a qualifier to those objects of
 exceptional historical value (if this is verifiable).

>>>
>>> We have a way of tagging objects of exceptional historical value, it's
>>> historic=*.  Objects of unexceptional historical value, or of no
>>> historical
>>> value do not get tagged with historic=*.  That's because historic is
>>> not a synonym (in the real world or in tagging) for old, disused or
>>> repurposed.
>>>
>>
>> just that it is not what we are currently doing.
>>
>> That is not what some of us are currently doing.  Others read the wiki
> page
> and tag accordingly.
>
> It occurs to me that some of the mis-tagging (as I see it) and some of the
> discussions here may revolve around semantics as interpreted by
> those who do not have English as a first language.  There is a
> difference between "historical" and "historic."
>
> Historians are concerned with historical data.  Old data (about
> populations, diseases or whatever) is historical data.  The
> assassination of a minor archduke, which seemed unimportant
> at the time, quickly turned into a historic event.
>
> When somebody says that "historic" applies to everything that
> historians do, that is incorrect.  What historians mostly do is
> look at historical data, some small fraction of which is
> also historic.
>
> See https://www.grammarly.com/blog/historic-historical/
> for a better explanation.
>
> So historic=* really should only apply (as the wiki page states) to the
> important
> things of the past, not everything some random historian might happen
> to be looking into.
>
> So the question is, do we accept that because some mappers have misused
> the tag we should encourage that misuse or do we discourage it?
>
> --
> Paul
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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] Deprecate water=pond?

2020-11-12 Thread Joseph Eisenberg
Re: is water=* tag needed?

On Thu, Nov 12, 2020 at 9:36 AM Brian M. Sperlongano 
wrote:
> "Is a water= tag even needed at all in these cases then? natural=water +
name="Foobar Pond" seems to cover it.  I'm not sure what specific added
information is conveyed by "lake", "pond", or even "lake_pond".  It's a
natural body of water with a name.  If we need tagging to indicate
freshwater vs brackish vs saltwater, or depth, or murkiness, those seem
like separate tags.

>
> > "I think the question here isn't if pond makes sense for data consumers.
Mappers are what matters in this case. If there is a little 4 meter pond,
mappers will not tag it as a lake because it sounds wrong. So they will
probably tag it just natural=water. But then we lose information about if
it is a little lake, a reservoir, a fountain or a wastewater dump. That's
why we need the pond."

So originally all lakes and semi-natural ponds were tagged just
natural=water, while reservoirs were landuse=reservoir,
retention/detention/infiltration basins were landuse=basin, the area of
 rivers was mapped with waterway=riverbank. And then, as now
leisure=swimming_pool was used for swimming pools, while seas and coastal
waters were delimited with natural=coastline ways (as they still are). Salt
ponds could be mapped with landuse=salt_pond.

This meant that there were separate tags for seas and marine water (all
areas outside of the coastline), for natural inland still water
(natural=water), man-made still water features (landuse=reservoir / =basin
/ =salt_pond), and for rivers (waterway=riverbank) - which are natural
flowing watercourses.

But there wasn't a clear way to map the area of a canal or ditch: an
artificial area of flowing water, so the tagging system was missing one
ingredient.

Some mappers used waterway=riverbank since canals are similar to rivers,
while others used natural=water even though this was for lakes.

Instead of making a new tag for canals or ditches or drains, its was
proposed to just use natural=water for all inland water areas, including
rivers, canals, reservoirs, and basins, with the addition of the tag
water=* to describe the type of water area. This was somewhat
controversial, since it meant mapping man-made watercourses and waterbodies
under natural=* but it was approved:
https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details (Apparently
this was already in use in Russia before it was adopted by the global
community?)

Now the proposal had a couple problems: it suggested water=cove and
water=lagoon for areas which are clearly outside of the coastline and part
of the marine water system, but in practice this has not happened,
natural=bay has been used for these areas instead of natural=water, so the
distinction between marine and inland water has remained mostly clear
(except in the difficult situation of estuaries).

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.

I wish it was possible to just redefine water=pond as "a man-made pond",
but since this is not likely to succeed, we should provide clear
alternatives.

Of course it will remain possible to just use natural=water with no
additional tag, if it's not known whether an inland body of still water is
man-made or natural.

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


Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread Janko Mihelić
I think the question here isn't if pond makes sense for data consumers.
Mappers are what matters in this case. If there is a little 4 meter pond,
mappers will not tag it as a lake because it sounds wrong. So they will
probably tag it just natural=water. But then we lose information about if
it is a little lake, a reservoir, a fountain or a wastewater dump. That's
why we need the pond.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread Joseph Eisenberg
Yes, it matters if it's flowing water, because rivers/streams (and
artificial waterways like canals, ditches and drains) are clearly distinct
from standing water bodies like lakes, reservoirs and basins. This is a
clearly observable difference which local mappers can survey.

Currently a number of map styles render flowing water (rivers, streams and
canals) differently than standing inland water or sea water.

Database users might want to calculate the total area of streams and rivers
in a country, and compare it to the total area of standing inland waters.
They also might want to compare the number or size of natural water bodies
to the number or size of artificial water bodies.

Since the difference between these is usually observable and verifiable, we
should have tags available that mappers can use.

Of course there will always be edge cases where it can be hard to decide if
a certain water body is a small natural lake or a semi-artificial pond, but
in that case mappers can just use natural=water without a water=* tag.

There are also edge-cases between rivers and estuaries at the junction with
the sea, and we should probably decide on a way to map this, but that's for
another time. Suffice to say that 99% of the time it's obvious if an area
of water is a flowing river vs a still-water lake. And similarly, canals
can usually be clearly distinguished from rivers based on their appearance,
and local knowledge of residents of the area.

So we should make sure our tagging distinguishes sea water from inland
still waters and flowing rivers, and also distinguish artificial from
natural water bodies and watercourses

-- Joseph Eisenberg

On Thu, Nov 12, 2020 at 3:50 AM OSM  wrote:

>
>
> Am 11.11.2020 um 18:25 schrieb Peter Elderson:
> > I am getting a foot vs hiking feeling. Everybody knows a difference,
> > nobody has the same difference. In the end, it does not matter.
>
> Hmm - does it matter, if it is a river or a stream or a lake or a pond?
> Especially a lake with a river flowing through?
> Or is it not all and everything only water - and a name somewhere ...
> Why does the water=* tag exist anyway? To distinguish between flowing
> and standing waters? Don't say so - see above.
>
> --
> Diese E-Mail wurde von AVG auf Viren geprüft.
> http://www.avg.com
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread Brian M. Sperlongano
Is a water= tag even needed at all in these cases then? natural=water +
name="Foobar Pond" seems to cover it.  I'm not sure what specific added
information is conveyed by "lake", "pond", or even "lake_pond".  It's a
natural body of water with a name.  If we need tagging to indicate
freshwater vs brackish vs saltwater, or depth, or murkiness, those seem
like separate tags.

On Thu, Nov 12, 2020, 12:26 PM Clifford Snow 
wrote:

> Out of curiosity I decided to look at how USGS defines lakes and ponds
> after noticing that their Feature Code is listed as lake/pond. Here is how
> they define the two, as well as rivers and streams and mountains and hills.
>
>
>
>
>
>
>
> *There are no official definitions for generic terms as applied to
> geographic features. Any existing definitions derive from the needs and
> applications of organizations using those geographic features. The
> Geographic Names Information System (GNIS) database utilizes 63 broad
> categories of feature types defined solely to facilitate retrieval of
> entries with similar characteristics from the database.These categories
> generally match dictionary definitions, but not always. The differences are
> thematic and highly subjective. For example, a lake is classified in the
> GNIS as a "natural body of inland water”, which is a feature description
> that can also apply to a reservoir, a pond, or a pool. All "linear flowing
> bodies of water" are classified as streams in the GNIS. At least 121 other
> generic terms fit this broad category, including creeks and rivers. Some
> might contend that a creek must flow into a river, but such hierarchies do
> not exist in the nation's namescape. The U.S. Board on Geographic Names
> once stated that the difference between a hill and a mountain was 1,000
> feet of local relief, but this was abandoned in the early 1970s. Broad
> agreement on such questions is essentially impossible, which is why there
> are no official feature classification standards.*
>
>
> I think they are smart to not try to classify lakes and ponds separately.
> Back to the original discussion started by Joseph Eisenberg, I'd be in
> favor of just using water=lake/pond or water=lake_pond.
>
> Best,
> Clifford
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> 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?

2020-11-12 Thread Clifford Snow
Out of curiosity I decided to look at how USGS defines lakes and ponds
after noticing that their Feature Code is listed as lake/pond. Here is how
they define the two, as well as rivers and streams and mountains and hills.







*There are no official definitions for generic terms as applied to
geographic features. Any existing definitions derive from the needs and
applications of organizations using those geographic features. The
Geographic Names Information System (GNIS) database utilizes 63 broad
categories of feature types defined solely to facilitate retrieval of
entries with similar characteristics from the database.These categories
generally match dictionary definitions, but not always. The differences are
thematic and highly subjective. For example, a lake is classified in the
GNIS as a "natural body of inland water”, which is a feature description
that can also apply to a reservoir, a pond, or a pool. All "linear flowing
bodies of water" are classified as streams in the GNIS. At least 121 other
generic terms fit this broad category, including creeks and rivers. Some
might contend that a creek must flow into a river, but such hierarchies do
not exist in the nation's namescape. The U.S. Board on Geographic Names
once stated that the difference between a hill and a mountain was 1,000
feet of local relief, but this was abandoned in the early 1970s. Broad
agreement on such questions is essentially impossible, which is why there
are no official feature classification standards.*


I think they are smart to not try to classify lakes and ponds separately.
Back to the original discussion started by Joseph Eisenberg, I'd be in
favor of just using water=lake/pond or water=lake_pond.

Best,
Clifford

-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread Joseph Eisenberg
Re: "what about artificial lakes that are not for storing water?"

Most of those are landuse=basin (or water=basin + natural=water if you
prefer the newer tagging scheme), and while they are not exactly for
"storing water", they might be for "preventing flooding", or "temporarily
holding excess water" or "permanently holding waste water."

I believe a landuse=reservoir or water=reservoid feature is going to
presumed to have a dam at one end which was built to keep in the water.

Flooded quarries and old mines are an interesting exception. I suppose a
old pit mine is not exactly a reservoir in the common understanding,
because the hole in the ground was built to remove minerals, and usually it
only fills up with water after the mining activity is finished and pumps to
extract water are turned off; there is usually no dam (though sometimes a
dam might be built later to prevent flooding).

It's also not exactly a landuse=basin because  the hole in the ground was
not made to hold water.

Perhaps water=quarry or something like that would be helpful, when it's
obvious that the water feature is an abandoned open pit mine or quarry.

On Thu, Nov 12, 2020 at 4:41 AM Martin Koppenhoefer 
wrote:

> Am Do., 12. Nov. 2020 um 02:33 Uhr schrieb Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> Ok, it looks like enough people feel that a very small artificial water
>> body, like a decorative pond in a residential garden, shouldn't be tagged
>> as water=reservoir or water=basin, so we need a replacement.
>>
>> The current problem with water=pond is that many are completely natural
>> features, but almost all other values of water=* are clearly natural (or
>> semi-natural), or clearly artificial, so water=pond is losing this
>> information which otherwise should be conveyed by the key water=*.
>>
>
>
> water=lake does not tell you about it being "natural" or not either. I am
> not sure what the term "natural" means. If a woman makes a depression in
> the terrain, and it automatically fills up with (surface or ground) water
> because of the geological conditions, is this "natural" or not? What about
> a woman sealing the terrain and conducting water to a place where there
> wasn't a water body before?
>
> This is a flooded open pit mine, is it "natural" or not, and if not, what
> would be the osm tag for it? water=lake, natural=no?
> https://www.lmbv.de/files/LMBV/Fotos/Nachrichten/Archivierte%20Nachrichtenfotos/LMBV_1616.jpg
>
> What about a lake without water (drained)? Is "lake" a term that can only
> be used for water bodies, or are dry lakes ok? Example:
> https://www.openstreetmap.org/#map=13/41.9975/13.5625 (everything
> "yellow" is a lake / former lake (actually third largest lake in Italy):
> https://en.wikipedia.org/wiki/Fucine_Lake
>
>
>> - water=fountain
>> - water=fishpond
>>
>
>
> -1 to "fishpond". It is not defined in the wiki, and is discouraged as
> likely a mistake: https://wiki.openstreetmap.org/wiki/Key:water (and I
> agree it is not good). You can have fish in many kinds of water bodies, I
> just recently started to add fish=yes to fountains when there are fish
> inside.
>
>
>>
>> And as mentioned before, there are water=reservoir (A reservoir
>>  or an artificial lake is used
>> to store water. )
>>
>
>
> what about artificial lakes that are not for storing water?
>
> Cheers
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature Proposal - Voting - Admission relations

2020-11-12 Thread Janko Mihelić
I started the voting process on the Admission proposal. Admission is a
potential new concept in OpenStreetMap, and it might get updated in the
future, but I think this is a good first step. Thanks for taking the time
to vote and comment!

https://wiki.openstreetmap.org/wiki/Proposed_features/Admission

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


Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread Martin Koppenhoefer
Am Do., 12. Nov. 2020 um 02:33 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> Ok, it looks like enough people feel that a very small artificial water
> body, like a decorative pond in a residential garden, shouldn't be tagged
> as water=reservoir or water=basin, so we need a replacement.
>
> The current problem with water=pond is that many are completely natural
> features, but almost all other values of water=* are clearly natural (or
> semi-natural), or clearly artificial, so water=pond is losing this
> information which otherwise should be conveyed by the key water=*.
>


water=lake does not tell you about it being "natural" or not either. I am
not sure what the term "natural" means. If a woman makes a depression in
the terrain, and it automatically fills up with (surface or ground) water
because of the geological conditions, is this "natural" or not? What about
a woman sealing the terrain and conducting water to a place where there
wasn't a water body before?

This is a flooded open pit mine, is it "natural" or not, and if not, what
would be the osm tag for it? water=lake, natural=no?
https://www.lmbv.de/files/LMBV/Fotos/Nachrichten/Archivierte%20Nachrichtenfotos/LMBV_1616.jpg

What about a lake without water (drained)? Is "lake" a term that can only
be used for water bodies, or are dry lakes ok? Example:
https://www.openstreetmap.org/#map=13/41.9975/13.5625 (everything "yellow"
is a lake / former lake (actually third largest lake in Italy):
https://en.wikipedia.org/wiki/Fucine_Lake


> - water=fountain
> - water=fishpond
>


-1 to "fishpond". It is not defined in the wiki, and is discouraged as
likely a mistake: https://wiki.openstreetmap.org/wiki/Key:water (and I
agree it is not good). You can have fish in many kinds of water bodies, I
just recently started to add fish=yes to fountains when there are fish
inside.


>
> And as mentioned before, there are water=reservoir (A reservoir
>  or an artificial lake is used
> to store water. )
>


what about artificial lakes that are not for storing water?

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


Re: [Tagging] Tagging becoming more mature

2020-11-12 Thread stevea
On Nov 12, 2020, at 3:18 AM, bkil  wrote:
> Although, I understand that there could exist some special meanings of
> the word "park":
> https://en.wiktionary.org/wiki/park

Jó napot, bikl!

There is quite a bit of history here, both past (early in OSM, as leisure=park 
developed and was both correctly and incorrectly deployed around the world), 
recently (as in a year ago / summer 2019 during the “leisure=park wiki 
incidents”) and presently (as in a developing draft proposal for Park boundary 
noted below).  I was and am personally involved in the latter two.

Differing definitions of “park” aren’t “special,” but differences in dialect.  
The wiktionary definitions are limited, as they don’t offer clear dialectical 
differences between British English and US English, where the distinctions are 
both real and quite sharp (the use of a certain idiolect of “park” often used 
in the US state of Colorado, as in the Middle Park basin, is noted in the 
wiktionary page as “US").  Better (for the present purpose we discuss now) is 
the very widely encompassing definition found at Wikipedia you quote, also 
repeatedly quoted in OSM’s wiki media (e.g. for both leisure=park as well as a 
proposal I co-author at 
https://wiki.osm.org/wiki/Proposed_features/Park_boundary ).  Coincidentally 
(and fulll disclosure), I believe I substantially wrote that introductory 
paragraph in the Wikipedia article’s definition, which if memory serves me, 
came from a talk-page contribution I made here in OSM (2011?  2012?).

> And anyway, terms must be understood in their GB sense within
> OpenStreetMap as declared by the project.

I disagree, with very narrow scope, in the instant (present) case.  Insisting 
on simplistic understandings of “GB English only” can cause outrageous 
misunderstandings, to which I can personally attest by being banned from wiki 
writing for two weeks last year as I struggled to untangle exactly this issue 
(though was plagued by a notorious OSM troll).  Much, much better (smarter for 
OSM, with much less rancor and long-term misunderstanding) is to more 
comprehensively understand that these linguistic differences are quite real, 
and to better accommodate them during OSM’s syntactic design phases (while 
“coining new tags” or attempting to better design tags, as we do here).

So, while leisure=park DOES remain (and should, for historical and “already 
established” reasons) in OSM, you can see how US English speakers, who have a 
MUCH broader definition of “park” than that in British (GB) English, are 
frustrated by the “limited” definition of leisure=park:  how do OSM 
Contributors in the USA, who speak US English and have thousands of what we 
call “parks” (but are NOT well-tagged with leisure=park), tag our “parks”?

We better develop that in our proposal, though are only in early stages now; it 
will take some time to complete the multiple proposal introductions that are 
planned to systematically roll out to gently do that (we hope).  But this 
process is now underway, thank you (all of OSM) for your patience.

Bottom line:  while it is good to know some of what appear to be “hard and fast 
rules of OSM,” (like “always GB English”), sometimes a greater / wider 
understanding of linguistics (dialects, how differences among them can be — 
even sometimes MUST be — accommodated in careful syntax / tagging in OSM) is 
deeply helpful to the project continuing to work (without misunderstanding and 
even rancor) internationally.  After all (and I don’t wish to be 
English-centric in our worldwide project, even as we use it here), there are 
dozens — perhaps in the low hundreds — of dialects of English around the world. 
 Avoiding misunderstandings based on these differences is something OSM wants 
to continue to do well into the future.  I know I certainly count myself among 
those wish this harmony to continue.  This can be difficult, and even (like 
here) sometimes must be explicitly spelled out, but with clarity, we can 
understand how to solve the difficulties of such dialectical ambiguities.

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


Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread OSM



Am 11.11.2020 um 18:25 schrieb Peter Elderson:
I am getting a foot vs hiking feeling. Everybody knows a difference, 
nobody has the same difference. In the end, it does not matter.


Hmm - does it matter, if it is a river or a stream or a lake or a pond?
Especially a lake with a river flowing through?
Or is it not all and everything only water - and a name somewhere ...
Why does the water=* tag exist anyway? To distinguish between flowing 
and standing waters? Don't say so - see above.


--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com


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


Re: [Tagging] Tagging becoming more mature

2020-11-12 Thread bkil
Although, I understand that there could exist some special meanings of
the word "park":
https://en.wiktionary.org/wiki/park

The most widely understood meaning also documented in Wikipedia seems
to be consistent:
https://en.wikipedia.org/wiki/Park

And anyway, terms must be understood in their GB sense within
OpenStreetMap as declared by the project.

On Thu, Nov 12, 2020 at 3:36 AM stevea  wrote:
>
> What I've said here (about ponds) is something I think a lot of us have long 
> recognized:  syntactic design of the sort that Joseph originally expressed 
> concern about, where maybe we deprecate a tag, somebody disagrees, somebody 
> else proposes differences, yet somebody else says "the subject is richer than 
> that and deserves a full design..." is hard work.
>
> There is a fair bit of tagging in OSM which might be described as "poor in 
> hindsight" that works (and in some cases worked) OK for a while, but when 
> brought into the larger world, begins to crack around its edges.  Some of 
> this is due to linguistic differences around the world (e.g. leisure=park 
> conflicting with the use of "park" in US English), some of this is due to 
> hasty and poor syntactic design of the tag in the first place.  Some of this 
> is due to reasons I'm not mentioning, as maybe we don't even (yet) fully 
> understand why some of what we do might not be quite good enough to grow into 
> our future.
>
> While I'm not proposing any specific fixes to these longer-term challenges to 
> OSM, I am saying that good syntactic design (and when appropriate, formal 
> proposals to implement them) is an important element to minimizing the risks 
> of how we've been doing this during our first couple of decades.  As OSM 
> grows from adolescence into adulthood, (16 years and growing!) I believe we 
> can keep our "plastic tagging where we can coin a new key" so it remains 
> intact, as such free-form tagging is an important flexibility built into the 
> project.  However, as we mature, become more worldwide (linguistically 
> diverse, accommodating similar-yet-different aspects of many things, both in 
> slight naming differences and slight actual differences...) we must consider 
> more mature methods to implement well-designed aspects like sound, 
> future-proof tags.  This includes both improvements to existing tags as well 
> as new tags.
>
> I love the spirited discussions that happen here and other places in OSM 
> where a variety of voices come together to discuss new ideas, new tags and 
> new ways to map:  may this wonderful spirit live on forever in our project.  
> Yet, we can also simultaneously recognize that there are "grown-up" methods 
> to designing "industrial strength, world-ready" aspects to the project that 
> will last and last far into our future.  Let's find ways to keep both going 
> strong, whether it's moving more to formal proposals (or not), other more 
> formal methods (or not) and keeping great, inclusive, respectful dialog alive 
> as we do so.
>
> SteveA
> ___
> 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?

2020-11-12 Thread stevea
nathan case wrote:
Not only is this often incredibly difficult to verify, it also leads to this 
complex situation of needing multiple tags for what are, essentially, the same 
features.

A well-designed tagging scheme (doesn’t have to be a formal proposal, but 
benefits greatly by being dressed up as one) allows us, as other tagging 
schemes do, to apply tags sparsely if only sparse details are known about a 
feature to be mapped.  If greater detail is known, the syntax structure 
specifies how to denote it.  That’s an excellent example of one important part 
of good syntax design.

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


Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread nathan case
I strongly disagree with the notion of splitting ponds and lakes by natural or 
artificial/man-made.

Not only is this often incredibly difficult to verify, it also leads to this 
complex situation of needing multiple tags for what are, essentially, the same 
features.

The current notion of an artificial/man-made lake being a reservoir is 
non-sense. Artificial lakes are still lakes. Additionally, not all reservoirs 
are artificial – some are natural.

Best.

From: Joseph Eisenberg 
Sent: Thursday, November 12, 2020 1:30 AM
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Deprecate water=pond?

Ok, it looks like enough people feel that a very small artificial water body, 
like a decorative pond in a residential garden, shouldn't be tagged as 
water=reservoir or water=basin, so we need a replacement.

I can see the logic behind that, if a reservoir is thought to be larger and 
must have a dam on one side, and a basin is artificially graded. A small koi 
pond or decorative pool isn't exactly the same.

The current problem with water=pond is that many are completely natural 
features, but almost all other values of water=* are clearly natural (or 
semi-natural), or clearly artificial, so water=pond is losing this information 
which otherwise should be conveyed by the key water=*. Since it is unlikely 
that we could check 1 million water=pond features quickly, it's not reasonable 
to redefine the meaning of this tag, but we can create a new tag or several 
replacement tags which are more specific, and encourage use of those instead.

But we need to have a clear description which will translate into other 
languages and cultures. For example, in Papua Indonesia, most Trans-New Guinea 
languages use 1 word for all types of "water", including rivers, streams, 
lakes, and the sea, so they won't see a difference between a "lake" and a 
"pond" unless you clearly describe it.

There are already several other more specific tags for small artificial water 
bodies, in use:
(https://taginfo.openstreetmap.org/keys/?key=water#values)
- water=reflecting_pool - "A reflecting pool: a water feature found in gardens, 
parks, and at memorial sites. It usually consists of a shallow pool of water, 
undisturbed by fountain jets, for a calm reflective surface."
- water=moat - A deep, wide defensive ditch, normally filled with water, 
surrounding a fortified habitation.
- water=wastewater - A clarifier/settling basin of a wastewater treatment plant.
- water=fountain
- water=fishpond

And as mentioned before, there are water=reservoir (A 
reservoir or an artificial lake is 
used to store water. ) and water=basin (An area of land artificially graded to 
hold water.)

So perhaps we could create a new tag water=natural_pond for small, natural or 
semi-natural lakes which are currently tagged as water=pond, and 
water=artificial_pond or water=man_made_pond for the majority of water=pond 
features which are clearly not natural, such as ponds in gardens.

-- Joseph Eisenberg


On Tue, Nov 10, 2020 at 1:59 AM Andy Mabbett 
mailto:a...@pigsonthewing.org.uk>> wrote:
>
> On Tue, 10 Nov 2020 at 05:26, Joseph Eisenberg
> mailto:joseph.eisenb...@gmail.com>> wrote:
>
> > I think the best option is to deprecate water=pond and suggest using 
> > water=lake for
> > natural lakes, even small ones, and use water=reservoir or water=basin (or
> > landuse=reservoir or =basin if you prefer) for the artificial ones.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecate water=pond?

2020-11-12 Thread Peter Elderson
I am surprised nobody has suggested a pondness or lakicity scale yet.

Best, Peter Elderson


Op do 12 nov. 2020 om 02:46 schreef stevea :

> If we're going to do "this:"
> > So perhaps we could create a new tag water=natural_pond for small,
> natural or semi-natural lakes which are currently tagged as water=pond, and
> water=artificial_pond or water=man_made_pond for the majority of water=pond
> features which are clearly not natural, such as ponds in gardens.
>
> it seems we should ponder (sorry, couldn't resist) the myriad
> possibilities for ponds both artificial AND natural and make a formal
> proposal that "covers all cases," at least as best we can in a formal
> proposal.  This would clarify (sorry, couldn't resist) what they're all
> "used for," as in settling in the case of a wastewater treatment plant,
> decorative as in somebody's backyard garden, natural, as in "shallow,
> nature-created, not-deep-enough to be called lake..." and so on.  Don't
> forget to consider (and document) potential overlap with things like
> leisure=swimming_pool and possibly others.
>
> We might get a good start on doing this in a talk page, but I think it
> would greatly benefit from the thought that goes into a formal proposal:
> worldwide consideration of the semantic space being described, rather clear
> syntax and namespaces described, how to decide one from the other,
> linguistic differences (as Joseph mentioned there can be a flattening in
> particular languages that might deserve extra clarity), how to migrate from
> existing tagging to the proposed tagging, and all the rest that formal
> proposals treat (what wiki need to update, et cetera).
>
> I admire Joseph's "tossing here" what he wrote, as it gets things started,
> but I believe the subject is much richer than this.
>
> It would also focus efforts by those who care and in as much detail and in
> one place as such a specific topic deserves.  While I don't write this to
> discourage posts to this list (I don't, as this list is a valuable place to
> discuss), I have also noticed a trend towards formal proposals.  "Ponds"
> seems like an excellent candidate for one.
>
> SteveA
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging