Re: [Talk-us] Parks, again

[Doug Hembry]

Thanks for the advice, Mateusz. I'll think about this some more, and if 
it still seems like a good idea I'll propose it on github. Andy Townsend 
gave me the same advice.

Best regards

- doug


On 1/7/2018 4:06 PM, Mateusz Konieczny wrote:
> For start: the best place to propose improvements to default map
> style is to propose it at
> https://github.com/gravitystorm/openstreetmap-carto
>
> In other places it is highly unusual that somebody involved in
> development map style will notice it and on issue tracker
> ( https://github.com/gravitystorm/openstreetmap-carto/issues ) proposed
> ideas stay under implementation or rejection so nothing is missed
> (though somebody still need to implement it),
>
>
> On Sun, 7 Jan 2018 19:58:54 +
> Doug Hembry  wrote:
>
>> You are right that I raised the issue of the green fill for
>> leisure=park because it is being used for large, wild protected
>> lands
> That is clearly incorrect tagging. But I guess that these people would
> just switch to leisure=pitch or leisure=garden if
> rendering for leisure=park would be removed.
>
>> I'm not sure what you meant about the national_park borders... I'm
>> sorry. Could you clarify?
> https://wiki.openstreetmap.org/wiki/Tag:boundary=national%20park?uselang=en
> is already rendered so I am curious why people still tag for renderer
> and use leisure=park in places that are something completely diffferent.
> Typically it stops when correct tagging is also displayed.
>
>> And it's really no big inconvenience for mappers to
>> add landuse=grass (or whatever) to their definition of a small urban
>> park.
> Note that in my experience (limited to Europe) it is very unusual for
> entire park to have a single land cover (either grass or trees or
> anything else) and it is vastly simpler to draw park area than many
> landcover=* or landuse=* areas.
>
>
>> On the other hand, one could argue that since the natural=*,
>> landcover=* (and even landuse=*) tags exist, why should we be
>> providing another, special way of fill-coloring parks (even small
>> urban parks)?
> Primarily - to display something useful also in areas that are not fully
> mapped (what is quite rare).
>
>> would be
>> to drop rendering for "boundary=national_park" and
>> "leisure=nature_reserve" as well
> I would not expect it to happen soon. Especially as this tagging is not
> terrible and is simpler than proposed new one and widely used.
>
> Completely broken waterway=wadi tag still haunts us (see
> https://github.com/gravitystorm/openstreetmap-carto/issues/1365 ) for
> links to gory details.
> .
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks, again

[Mateusz Konieczny]

For start: the best place to propose improvements to default map
style is to propose it at
https://github.com/gravitystorm/openstreetmap-carto

In other places it is highly unusual that somebody involved in
development map style will notice it and on issue tracker
( https://github.com/gravitystorm/openstreetmap-carto/issues ) proposed
ideas stay under implementation or rejection so nothing is missed
(though somebody still need to implement it),


On Sun, 7 Jan 2018 19:58:54 +
Doug Hembry  wrote:

> You are right that I raised the issue of the green fill for
> leisure=park because it is being used for large, wild protected
> lands

That is clearly incorrect tagging. But I guess that these people would
just switch to leisure=pitch or leisure=garden if
rendering for leisure=park would be removed. 

> I'm not sure what you meant about the national_park borders... I'm 
> sorry. Could you clarify?

https://wiki.openstreetmap.org/wiki/Tag:boundary=national%20park?uselang=en
is already rendered so I am curious why people still tag for renderer
and use leisure=park in places that are something completely diffferent.
Typically it stops when correct tagging is also displayed.

> And it's really no big inconvenience for mappers to 
> add landuse=grass (or whatever) to their definition of a small urban 
> park.

Note that in my experience (limited to Europe) it is very unusual for
entire park to have a single land cover (either grass or trees or
anything else) and it is vastly simpler to draw park area than many
landcover=* or landuse=* areas.


> On the other hand, one could argue that since the natural=*,
> landcover=* (and even landuse=*) tags exist, why should we be
> providing another, special way of fill-coloring parks (even small
> urban parks)?

Primarily - to display something useful also in areas that are not fully
mapped (what is quite rare).

> would be 
> to drop rendering for "boundary=national_park" and 
> "leisure=nature_reserve" as well

I would not expect it to happen soon. Especially as this tagging is not
terrible and is simpler than proposed new one and widely used.

Completely broken waterway=wadi tag still haunts us (see
https://github.com/gravitystorm/openstreetmap-carto/issues/1365 ) for
links to gory details.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks, again

[Doug Hembry]

On 1/7/2018 12:52 PM, Kevin Kenny wrote:
On Sun, Jan 7, 2018 at 2:58 PM, Doug Hembry 
> wrote:
Briefly, my personal preference (for what it's worth), assuming
rendering is added at some point for "boundary=protected_area", would be
to drop rendering for "boundary=national_park" and
"leisure=nature_reserve" as well (as I'm suggesting for "leisure=park").
The "boundary=national_park" tag is redundant, given
"boundary=protected_area and protect_class=2 and
protection_title=national_park". IMHO, it could be deprecated. I don't
have an opinion on "leisure=nature_reserve". Maybe there's some value to
keeping it as part of the set of "leisure=*" values that describe
facilities for human recreation, but it doesn't need to explicitly render.

I have 'leisure=nature_reserve' on a lot of things so that they
will render with the renderer that we have.
+1 (or they use "boundary=national_park", then "boundary:type=protected_area" 
for the same reason)

I've been trying hard to make sure that they are
also tagged with 'boundary=protected_area protect_class=*
access=*' as well, so that when and if the renderer shifts
to protected areas, I'm good to go.

While posting this,
I discovered that I've missed a few, but I need to do
research to figure out what protect_class they are.
That's one reason that I don't like requiring that
'protect_class' be the only driver. It's often not observable
on the ground. I can't tag it correctly until and unless
I've done some non-field investigation.

+1  It seems probable that some people using the boundary=protected area set 
will initially skip the protect_class=* tag, or defer providing it, although 
the table in the wiki is useful. It will likely get filled in eventually by 
someone, and in the meantime, if/when the renderer supports these tags, it will 
probably have to tolerate a missing protect_class tag, maybe by assuming a 
default value (?)I've also done some limited landcover with a few areas
like https://www.openstreetmap.org/relation/6467468,
but I find it to be really slow going (getting it right involves
comparing summer and winter images, for instance).
In maps that I render, I ordinarily derive landcover
from non-OSM sources, so getting landcover for me
has a very low priority - I mostly map what I plan to
render. (Also called, "scratching your own itch.")
We're lucky in sunny CA, in that it's pretty clear from imagery where are the 
edges of woods, scrub or grasslands, etc. Season doesn't seem to cause 
problems. But around here, landcover that people have imported in the past 
tends to grossly inaccurate.

A fair number of 'national parks' are actually class 5 or 6, owing
to inholdings and private-public partnerships. They usually have
1b's and 2's embedded within them.

OK.. hadn't noticed this, but my point was that the protect_title tag documents 
that this is
a National Park.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks, again

[Kevin Kenny]

On Sun, Jan 7, 2018 at 2:58 PM, Doug Hembry  wrote:

> Briefly, my personal preference (for what it's worth), assuming
> rendering is added at some point for "boundary=protected_area", would be
> to drop rendering for "boundary=national_park" and
> "leisure=nature_reserve" as well (as I'm suggesting for "leisure=park").
> The "boundary=national_park" tag is redundant, given
> "boundary=protected_area and protect_class=2 and
> protection_title=national_park". IMHO, it could be deprecated. I don't
> have an opinion on "leisure=nature_reserve". Maybe there's some value to
> keeping it as part of the set of "leisure=*" values that describe
> facilities for human recreation, but it doesn't need to explicitly render.
>

I have 'leisure=nature_reserve' on a lot of things so that they
will render with the renderer that we have.

I've been trying hard to make sure that they are
also tagged with 'boundary=protected_area protect_class=*
access=*' as well, so that when and if the renderer shifts
to protected areas, I'm good to go.

While posting this,
I discovered that I've missed a few, but I need to do
research to figure out what protect_class they are.
That's one reason that I don't like requiring that
'protect_class' be the only driver. It's often not observable
on the ground. I can't tag it correctly until and unless
I've done some non-field investigation.

I've also done some limited landcover with a few areas
like https://www.openstreetmap.org/relation/6467468,
but I find it to be really slow going (getting it right involves
comparing summer and winter images, for instance).
In maps that I render, I ordinarily derive landcover
from non-OSM sources, so getting landcover for me
has a very low priority - I mostly map what I plan to
render. (Also called, "scratching your own itch.")

A fair number of 'national parks' are actually class 5 or 6, owing
to inholdings and private-public partnerships. They usually have
1b's and 2's embedded within them.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Parks, again.

[Doug Hembry]

On 01/07/2018 21:11, Andy Townsend wrote:

| To be honest, I wouldn't "suggest that OSM Carto do X" here - there's
| been a lot of discussion already and no conclusions there. What I'd
|suggest instead is that someone knocks up a rendering of California
| based on what it would look like if boundary=protected_area, or
| protect_class, or whatever is used instead of park, nature_reserve
| and/or national_park.  It's not that complicated to do that - there are
| basic instructions for creating a tile server at .

A good suggestion, Andy, but I think a bit beyond my skill level and 
time constraints.
However, I take your point that talk-us is not the place to bring up 
issues with OSM carto.
I may shut up about it on talk-us and look into how to raise the issue 
on github..

Cheers..
- doug

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks, again

[OSM Volunteer stevea]

There is a lot to unpack in this discussion.

First, OSM has the strong tenet that we should not code (data tag) for the 
renderer.  That is sound advice and largely serves us well, but it fails to 
directly address that there is no point to being an OSM volunteer unless there 
ARE renderers which display the results of our mapping (tagging).  Well, if you 
spend time in the more "coding" aspects of our project, you can glean the 
largely opaque (to most OSMers) processes and personalities of renderers and 
rendering, and maybe that is appropriate:  after all, they are the "back end."  
Yes, this is where important decisions are made about what data in our map 
either are or are not shown.  (I'm talking about Carto, what might be called 
OSM's "front door" or "pretty face.")  Carto is, for better or worse (and it 
has gotten much better) what most mappers (and other OSM consumers, though not 
all) "see as OSM."  I know that's not strictly true, but let's say for purposes 
of this discussion about parks that it is.

Especially since having discovered OSM in 2009, I love cartography and mapping. 
 I also love parks, hiking, biking, nature and enjoying our public lands which 
are protected (at certain "levels") from further human development.  So, even 
as I got started mapping in OSM back then, accurately mapping parks (indeed, 
even positing ideas at how we might potentially improve how OSM maps parks, 
something I continue nine years later) became an important goal of mine in this 
project, reflected in my user page, mapping practices and passionate talk-us 
discussions.  I have followed many twists along the way, such as when 
leisure=nature_reserve is more correct than leisure=park, a lengthy debate 
(here) about landuse=forest (which I eventually cried "uncle" about, seeing 
that we were badly smearing the semantics of well-established wiki definitions, 
although they were and are ambiguous), striving to "do the right thing" with 
National Forests, National Parks, State Parks et al, important distinctions 
between landuse and landcover (still badly under-addressed in our project, as 
rendering distinctions between them remains muddy and has not fully emerged), 
the development of the protected_area (a good thing, but sorely lacking in 
helpfulness when it comes to being rendered — a difficult task, I realize) and 
other related topics.  It is quite complex, it is difficult to communicate 
about all the moving parts, let alone reach solid consensus, let alone render 
perfectly what we mean.

Tagging accurately, with well-designed and well-documented (in our wiki) schema 
are absolutely essential.  Rendering, at least at "some" level (a single 
renderer suffices, one, like Carto, which is also well-designed to carefully 
"map what is important and not map what is not important") isn't QUITE AS 
essential, but let's use the word "vital" or say "very important."  The full 
path from "volunteer entering data" to "seeing it blossom upon the map" is 
largely what drives the passion of OSM volunteers doing our good work.  So the 
choice of what to render (in Carto) is vital.  As we diligently enter map data, 
we are pulled forward by the sometimes-seemingly-contradictory desires of 
wanting to see beautiful renderings of our work as well as to rather precisely 
enter data, and not code for the renderer.  Threading that needle is not alway 
successful, and it is often thwarted, as I believe it is in this case (parks 
and related entities, what we might agree are "protected areas") by the 
distinct lack of these entities rendering well.  It is also complicated by the 
legacy of older/preceding tagging conventions.

We've done good work with developing the protected_area schema in our tagging 
syntax.  We haven't done good work rendering the full spectrum of what we mean 
by those.  Again, this is difficult.  Colors, confusion with landuse/landcover, 
ideas about dashing (whether jurisdiction, landcover, "use," or other — I'm 
open to all ideas) are valid topics to discuss.  Let's understand that there 
has been a medium-long arc of history (over a decade) in our project which must 
accommodate the way things were done two, five, ten years ago, as well as that 
we wish to move forward with more robust tagging schema AND better renderings 
of those schema.  In short, and it is widely known:  legacies can be 
challenging to grow beyond.

These are complex issues, we have been evolving them over years on top of doing 
things with more simplistic (legacy) methods, and so many issues must be 
accommodated in a "smart growth" (towards excellent tagging being supported by 
excellent rendering) methodology.  This forum may not be the best way to do 
that, as I feel I have typed too much for one missive already.  Please, let 
good discussion continue.  We are many people, with many good ideas, who wish 
to see the "right" and "best" things happen as our project grows and improves.  
Once again, I believe us to be more in 

Re: [Talk-us] Parks, again

[Doug Hembry]

Hi Mateusz,
You are right that I raised the issue of the green fill for leisure=park 
because it is being used for large, wild protected lands, where it 
causes problems for "natural" and "landcover" tagging. If mappers only 
used it for smallish, low-protection, usually urban parks, as the wiki 
defines, it wouldn't be such a problem since these parks are usually 
mainly grass anyway, and no-one bothers to define them in detail with 
"natural=*" or "landcover=*".

So, yes, the problem arises in what I think is tagging for the renderer. 
And yes, that means it's really not the renderer's problem. Agreed..

On the other hand, one could argue that since the natural=*, landcover=* 
(and even landuse=*) tags exist, why should we be providing another, 
special way of fill-coloring parks (even small urban parks)? It would be 
more consistent to use the same set of landcover tags for ALL park-type 
and protected areas. And it's really no big inconvenience for mappers to 
add landuse=grass (or whatever) to their definition of a small urban 
park. (Incidentally, the other leisure=* areas that are provided with a 
fill-color (garden, playground, dog_park,..) are almost guaranteed to be 
small, and a single color fill is no problem)

I'm not sure what you meant about the national_park borders... I'm 
sorry. Could you clarify?

I stayed away from "boundary=national_park" and "leisure=nature_reserve" 
topic so as not to muddy the water in my original note. But I think it's 
true that there is also tagging for the renderer going on with these 
tags too - to force boundary rendering for "boundary=protected_area" 
which isn't there at present.

Briefly, my personal preference (for what it's worth), assuming 
rendering is added at some point for "boundary=protected_area", would be 
to drop rendering for "boundary=national_park" and 
"leisure=nature_reserve" as well (as I'm suggesting for "leisure=park"). 
The "boundary=national_park" tag is redundant, given 
"boundary=protected_area and protect_class=2 and 
protection_title=national_park". IMHO, it could be deprecated. I don't 
have an opinion on "leisure=nature_reserve". Maybe there's some value to 
keeping it as part of the set of "leisure=*" values that describe 
facilities for human recreation, but it doesn't need to explicitly render.

I should add that my comments are based only on experiences of my local 
neck of the woods (CA State, and maybe the west coast of the US). I know 
you have to consider requirements from all over..
Thanks for reading this far..


On 1/6/2018 7:58 PM, Mateusz Konieczny wrote:
> On Sat, 6 Jan 2018 21:11:04 +
> Doug Hembry  wrote:
>
>> IMHO, AT THE VERY LEAST, the background green fill for leisure=park
>> could and should be dropped by openstreeetmap-carto - it is
>> unnecessary, causes problems, and can be replaced by natural=* or
>> landcover=* . This would reduce one incentive for inappropriate use,
>> and if still used inappropriately, it wouldn't matter so much.
> I am not sure. As I understand, problem is caused by tagging for
> renderer - but national park borders are already displayed in this
> style.
> .
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks, again

[Andy Townsend]

On 06/01/2018 21:11, Doug Hembry wrote:

(lots snipped, pretty much all of which I agree with)


IMHO, AT THE VERY LEAST, the background green fill for leisure=park
could and should be dropped by openstreeetmap-carto - it is unnecessary,
causes problems, and can be replaced by natural=* or landcover=* . This
would reduce one incentive for inappropriate use, and if still used
inappropriately, it wouldn't matter so much.
There's a discussion that touches on this at 
https://github.com/gravitystorm/openstreetmap-carto/issues/603 - it was 
initially proposed there to replace the rendering of 
leisure=nature_reserve with rendering protected_area.


leisure=park and leisure=nature_reserve were both designed for specific 
on-the-ground features, but there's been significant usage of both to 
"turn areas green" in the OSM Carto map style.




While on the topic of rendering "parks", I do agree with Steve (again,
if I'm understanding correctly) that  it would be valuable, if possible
at some point in the future - both for map clarity as well as providing
useful information to users - for carto to use different colors for
different types of boundaries. I differ with Steve in that IMO the
coloring should be based off protect_class (or at least for several
bands of protect_class if there are too many distinct values for
separate colors) rather than jurisdiction. Jurisdiction is less
meaningful to users than level of protection, and in any case is usually
obvious from the area name and other tags. Further, boundary rendering
should indicate access restrictions (access=yes/no/permit) by some means
- perhaps a dashed line as is presently done for highways.


To be honest, I wouldn't "suggest that OSM Carto do X" here - there's 
been a lot of discussion already and no conclusions there. What I'd 
suggest instead is that someone knocks up a rendering of California 
based on what it would look like if boundary=protected_area, or 
protect_class, or whatever is used instead of park, nature_reserve 
and/or national_park.  It's not that complicated to do that - there are 
basic instructions for creating a tile server at 
https://switch2osm.org/manually-building-a-tile-server-16-04-2-lts/ and 
California is small enough in OSM terms to fit on a virtual machine on 
an average desktop PC.


I did something similar for the UK - here 
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/c342d0e42aeec0219777535a16e4c025a8886bf1/style.lua#L362 
is a simple example of "it it's tagged like X, make it render like Y", 
and the result is the dashed lines around e.g. 
https://www.openstreetmap.org/way/144944672 on this map: 
https://map.atownsend.org.uk/maps/map/map.html#zoom=12=53.3107=-1.7177 
.  If anyone wants any help with that, please ask.  There's quite a lot 
of useful information around already, bt it is spread out in different 
places.


Best Regards,

Andy





___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks, again

[Mateusz Konieczny]

On Sat, 6 Jan 2018 21:11:04 +
Doug Hembry  wrote:

> IMHO, AT THE VERY LEAST, the background green fill for leisure=park 
> could and should be dropped by openstreeetmap-carto - it is
> unnecessary, causes problems, and can be replaced by natural=* or
> landcover=* . This would reduce one incentive for inappropriate use,
> and if still used inappropriately, it wouldn't matter so much.

I am not sure. As I understand, problem is caused by tagging for
renderer - but national park borders are already displayed in this
style.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Parks, again

[Doug Hembry]

Greetings everyone..

I have a stake in this discussion, being resident in CA and dealing 
regularly with the representation of the various state and local parks, 
Open Spaces, Ecological Reserves, water company lands, National Parks 
and Forests, etc, etc, with which this state is blessed. It's a crazy 
patchwork quilt of what are all, essentially, protected lands.

I'm broadly in agreement (I think) with Bradley White and other earlier 
posters and less so with Steve. My take is that "parks" differ 
essentially in their level of protection, and there is a whole spectrum 
of protection levels. These levels are already well described by the 
boundary=protected_area tag set. Protect_class encompasses a range from 
legally designated wilderness down to local urban parks (plus 
special-purpose areas). Protection_title=*, operator=*, and name=* 
capture information about the responsible jurisdiction (you can throw in 
"park_type" if you like, though it seems superfluous) and access=* 
(along with mapped trails, etc) describes the area's availability for 
public recreation. I don't think we need to embark on some big new 
program to determine how to map California's parks - we already have the 
means to do so. The boundary=protected_area might need some tweaking for 
national or local peculiarities and some discussion about what protect 
levels apply to what types of CA "parks", but it's already there and it 
works and we should just use it.

Protect_class is not just some abstract value of interest only to 
professional ecologists. The general "personality", and type of 
recreation available in a given park - ie, whether you take your dog and 
your kid in a stroller to picnic and play ball, or whether you carry 
survival equipment, bear spray, a PLB and GPS, or something in between - 
is strongly correlated  with level of protection. And given this, the 
importance of the leisure=park/nature_reserve tags for understanding 
"what kind of park is this?" is greatly decreased.

If I can throw in a note of cynicism: I have long suspected that there 
is a lot of deliberate tagging for the renderer going on in this whole 
business. I suspect the propensity for tagging anything with the word 
"Park" in it's name as leisure=park (given the wiki definition, 
seriously ?) stems from a belief by some mappers (no names) that the map 
is improved by fill-coloring all protected lands a light shade of green 
(It's gone so far that someone has been putting leisure=park on National 
Forests in Humboldt County). This is a terrible idea - apart from being 
totally counter to the wiki definition, the uniform green coloration of 
"parks" at medium to high zooms is incompatible with describing land 
cover characteristics with natural=* or landcover=*

IMHO, AT THE VERY LEAST, the background green fill for leisure=park 
could and should be dropped by openstreeetmap-carto - it is unnecessary, 
causes problems, and can be replaced by natural=* or landcover=* . This 
would reduce one incentive for inappropriate use, and if still used 
inappropriately, it wouldn't matter so much.

While on the topic of rendering "parks", I do agree with Steve (again, 
if I'm understanding correctly) that  it would be valuable, if possible 
at some point in the future - both for map clarity as well as providing 
useful information to users - for carto to use different colors for 
different types of boundaries. I differ with Steve in that IMO the 
coloring should be based off protect_class (or at least for several 
bands of protect_class if there are too many distinct values for 
separate colors) rather than jurisdiction. Jurisdiction is less 
meaningful to users than level of protection, and in any case is usually 
obvious from the area name and other tags. Further, boundary rendering 
should indicate access restrictions (access=yes/no/permit) by some means 
- perhaps a dashed line as is presently done for highways.

Happy New Year to all!

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks, again

[OSM Volunteer stevea]

On January 4, 2018 at 6:21:03 PM PST, Bradley White  
wrote:
>> I don't think the title
>> given to a piece of land should necessarily have bearing on the data
>> representation, in the same way "Hampstead Heath" doesn't get
>> "natural=heath" just because it's in the name.

I forgot to make this point in my previous post.  The British English 
convention of calling a (sometimes municipal) park-like area "Hampstead Heath" 
being explicitly stated as a different semantic than what OSM tags 
"natural=heath" is an important distinction to make, and I'm glad our wiki does 
so.

However, by way of contrast, something called "Park" generally IS a park:  I 
seldom, if ever, find an exception to this.  As long as that is true (and 
contrasts sharply with "heath" as you and our wiki remind us), I'll continue to 
tag something named "Park" with leisure=park.  Yes, sometimes I'll use 
leisure=nature_reserve, but guess what?  That's because it's name contains 
"Nature Reserve" or "Open Space Reserve" or some other set of English words 
that map directly onto the tag "leisure=nature_reserve."

So, while it doesn't NECESSARILY have bearing, I am an intelligent enough user 
of language (and its derived semantics) to "properly" map these semantics to 
specific syntax tags in OSM.  All OSM volunteers must do at least a little bit 
of this, and we can even talk about the more subtle aspects of doing so in a 
forum like talk-us.

Our tag of park, I continue to assert most assiduously, is vast and elastic.  
We might improve it with a rich schema, but until then, it is correct to tag 
park entries with this tag.

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks, again

[OSM Volunteer stevea]

On January 4, 2018 at 6:21:03 PM PST, Bradley White  
wrote:
>> As you say "feel like Type 2" I think is where it fuzzies in my mind.  Parks 
>> go to 3, 4, even 11 and beyond.  Parks have a wide range of "experiences" 
>> besides 1 and 2.
> 
> So do roads. There are countless kinds of roads, with varying levels
> of importance and physical features. Instead of using a catch-all
> "highway=road" tag, and instead of tagging infinitesimal levels of
> network importance (or any of the other countless possible metrics),
> we develop a classification system that allocates all roads into a
> small set of (semi)-easy-to-work-with-and-understand classes. Some
> roads don't fit well into this system, true. It isn't always clean; it
> can be ambiguous; it continues to be debated over, and that's fine.
> But, for the most part, it has worked, certainly better than the
> all-or-nothing alternatives would have.

I believe you are saying (agreeing) that "roads have many flavors."  Yes.  We 
have many highway=* tags to accommodate those, and while there remain some 
sticky difficulty in a few corner cases, as we map with values motorway, 
primary, trunk, secondary, tertiary... OSM (recall, "Street" is our middle 
name) does well as a result.  The tag "highway=road" is not a "catch-all" tag 
applied recklessly to any and all roads:  for the most part roads are tagged 
with the above (more correct, more precise) values and "highway=road" is left 
for more ambiguous cases, for example when fuzzy aerial imagery suggests a 
road/highway, but little or nothing else is known.  If I got any of that wrong, 
please gently correct me.  Although, I think we are largely in agreement:  we 
both (and many of us in OSM) use the highway= tag with little argument or 
consequence.  (Again, in a few minor cases, discussion continues).

> I agree with previous posters that this is same case with parks. In
> the same way that the fact that there is something different enough
> about a freeway and a narrow county back-road to represent them
> differently in the database, there is something different enough about
> a park I would take a kid to play on the playground for an hour, and a
> park that I can spend half the day mountain biking around in without
> encountering more than a small handful of people, that I think they
> should be differentiated between in our data. I don't think the title
> given to a piece of land should necessarily have bearing on the data
> representation, in the same way "Hampstead Heath" doesn't get
> "natural=heath" just because it's in the name.

I don't know to which previous posters you refer (this is a new thread I've 
broken off) and I am not sure of the point with which you are agreeing.  If I 
had to guess (I prefer not guessing) it seems you mean that OSM could benefit 
from a wide array of park tagging similar to how it enjoys a wide array of 
highway tagging.  I do not disagree, meaning I agree.  Sure, early on we seem 
to have "broken out" (from "generic parks") the specific semantic of 
"national_park."  As I said before, doing so (and where we are now), brings us 
up from one type of park (all of them) up to two (a certain kind of them 
excluding the rest), with two being a very small number.  There might be dozens 
or even hundreds of types of parks, and refining this to exactitude and full 
consensus all across Earth could take OSM decades, with much tedious and messy 
"sausage making" along the way.  Not that it wouldn't be valuable to do so (it 
would be) since as a result of those efforts, OSM might become one of the best 
park maps ever made of our whole planet.  Alas, as "street" IS our middle name, 
we've come closer to the goal of well-describing our highway networks, rather 
than our parks.  Though, parks (and many, many other objects in OSM) are 
somewhat well-represented, I think many agree.  We crawl before we walk, we 
walk before we run.

However, we haven't really well or fully described parks.  We only partially 
describe them, which "isn't nothing."  (I'm happy to accept this, use it to 
enter parks, AND improve on our park entry schema).  As I mentioned,  in 2009 
Apo42 in California got into the (good, in my opinion) habit of adding to a 
(partial, though substantial) statewide parks import a new (back then) tag of 
"park:type" which often blended jurisdiction, type of natural area and/or 
purpose.  For example, some of its values are county_park, state_beach and 
state_historical_reserve.  This was an early, first foray into better 
characterizing what California's Department of State Parks throws into a large 
bin called "parks," (all of them, from beaches to historical reserves) while 
using the state's own data to better sub-categorize them.  As you say, there 
are all kinds of purposes for what humanity calls "park" and it would be good 
for OSM to capture these aspects.  What we haven't done is talk about what vast 
issues this gives rise to, primary:  

Re: [Talk-us] Parks, again

[Bradley White]

> As you say "feel like Type 2" I think is where it fuzzies in my mind.  Parks 
> go to 3, 4, even 11 and beyond.  Parks have a wide range of "experiences" 
> besides 1 and 2.

So do roads. There are countless kinds of roads, with varying levels
of importance and physical features. Instead of using a catch-all
"highway=road" tag, and instead of tagging infinitesimal levels of
network importance (or any of the other countless possible metrics),
we develop a classification system that allocates all roads into a
small set of (semi)-easy-to-work-with-and-understand classes. Some
roads don't fit well into this system, true. It isn't always clean; it
can be ambiguous; it continues to be debated over, and that's fine.
But, for the most part, it has worked, certainly better than the
all-or-nothing alternatives would have.

I agree with previous posters that this is same case with parks. In
the same way that the fact that there is something different enough
about a freeway and a narrow county back-road to represent them
differently in the database, there is something different enough about
a park I would take a kid to play on the playground for an hour, and a
park that I can spend half the day mountain biking around in without
encountering more than a small handful of people, that I think they
should be differentiated between in our data. I don't think the title
given to a piece of land should necessarily have bearing on the data
representation, in the same way "Hampstead Heath" doesn't get
"natural=heath" just because it's in the name.

Currently, I use the tagging scheme detailed by Greg earlier. I am
certainly not opposed to using "leisure=park" along with a basic
classification tag, say "park=developed/undeveloped" or something, but
Greg's scheme has the benefit of using established tags with rendering
support that still more or less respect the definition and intent of
the tags. While "leisure=nature_reserve" has generally assumed some
kind of conservation status, I think the newish
"boundary=protected_area" tags do a much better job detailing land
conservation, and that "leisure=nature_reserve" is the perfect tag to
adopt for the type 1 parks which Greg talks about. These 'type 1'
parks are, after all, pieces of *nature* being *reserved* by a
government agency for *leisure* of the public.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks, again

[OSM Volunteer stevea]

On Jan 3, 2018, at 5:24 PM, Greg Troxel  wrote:
> I think the National Park term causes a lot of problems.   As I see it,
> there are two kinds of places:
> 
>  1) a natural area with some accomodation for human use, which is mostly
>  natural except for a few bits.
> 
>  2) a semi-natural area which has grass and trees (instead of
>  concrete), but is fairly manicured.  In this way it is more like a
>  maintained garden than wilderness..
> 
> Both of these exist at various scales.

I hear you.  I'm listening.  This is all true.  There are also 3), 4) and many, 
many others.  Yes.

Our definition of "park" (both as humans and in OSM) is quite elastic, let's 
face it.

As you say "feel like Type 2" I think is where it fuzzies in my mind.  Parks go 
to 3, 4, even 11 and beyond.  Parks have a wide range of "experiences" besides 
1 and 2.

> A "conservation area" in my town might be only 100 acres.  You are in
> the forest, with just a cleared trail and blazes.  But at the entrance,
> there is a dirt parking lot and a sign with a map.  This is a type 1
> area with a very small (enough for 10 cars) part that almost feels a
> little type 2 (except the parking lot is barely usable), but it's so
> small we just call it type 1.

Again, I hear this, this is true, I nod my head in agreement.  There is what we 
experience in the real world and yes, that maps directly onto a tag in OSM.  
Park is that.  States use it.  Nations use it.  "Come camp here for the night 
or a week" places which are commercial use it.  It is elastic in the real world 
and many use it, as we call myriad of them by using the name park in our speech 
as a noun.  It is a wide and flexible concept in human thinking, directly 
applied to all kinds of places around the world.  By billions of us.  
Frequently.

> Whether anybody (administrator of thing or not) uses the work Park is
> not relevant at all.

Mmm, no.  We (humanity, including administrators and the people) mean something 
as we use the word "park" together in wide harmony.  That is (at least partly!) 
why we tag with the word "park."

Yes, there are "local parks with benches and grass in our city."  Yes, there 
are "national parks."  We're only up to two, right there.  Then you get to 
their various scales.  There are many more than two.

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us