[Talk-us] Parks, again

Doug Hembry doughembry at hotmail.com
Sat Jan 6 21:11:04 UTC 2018

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!

More information about the Talk-us mailing list