[Tagging] Tagging of State Parks in the US

Paul Allen pla16021 at gmail.com
Sun Jul 28 15:37:10 UTC 2019


On Sun, 28 Jul 2019 at 15:42, Kevin Kenny <kevin.b.kenny at gmail.com> wrote:

>
> I dislike the numeric classification as well.
>

That's good.  We agree on something. :)

I dislike 'leisure=state_park' for two reasons.
>
> First, it preƫmpts the 'leisure' tag. It turns out that there are
> State Parks that are also something else in the 'leisure=*' space. A
> handful in New York are tagged 'leisure=golf_course' and should retain
> that tagging, but it would be good to have tagging that indicates the
> protection status.


Looks like we also agree there.  I have no problem with something tagged as
leisure=golf_course also having a protection status.  It's analagous to a
highway
of a particular type having an access tag.  Where I disagree is with the
people who
think that leisure=golf_course should, where it is protected, be replace by
protected_class=n.

Second, it pushes the problem down one level. Near me, there are
> 'County Parks' that are functionally pretty much the same as State
> Parks, and even 'County Forests', 'County Nature Preserves', 'County
> Wildlife Sanctuaries', and so on... and moreover, even some similar
> objects at the town level. What is significant is the protection, not
> the level of government that establishes it, so having 'state' in the
> name is simply a recipe for more confusion.


Ummmmm, what do you mean by "having state in the name"?  If you mean the
tag name, I agree.  State parks and county parks are still parks.  To some
degree
the operator tag is adequate to distinguish them.  But having "State" or
"County" in
name=* is perfectly fine.

The 'boundary=recreational_area' idea would work for me if people were
> actually to get behind it.


Something along those lines might work.  In the UK boundary is how we
handle national
parks that encompass a lot of things (such as towns) your country might not
consider to
be a park: https://www.openstreetmap.org/relation/165598 - it's not all
"nature" or "recreation"
but there are extra legal restrictions on activities such as building a
housing estate that don't
apply outside of the park.


> In fact, that would work with the IUCN codes as well - we don't have
> to use them unchanged, we can name them!


Not only could but should.  There is a computer programming language I hold
in contempt
but I grudgingly admit that its introduction of enumerated types was a good
idea.  We should
avoid magic numbers.

>
> I drafted the protected_area idea a short while before I learnt of the
> issue with the database, and learning of the issue has already made me
> less sanguine.


Yeah, that kyboshes a lot of ideas.  It also requires that editors know to
treat it as an
area object (but that's a lot less hassle to fix).


> The only thing that kept the idea alive for me was
> that 'area=yes' is available as a workaround,


Indeed.  One might consider that tagging for the renderer, but I'd say that
using a valid tag
in a valid way isn't wrong, it's lying for the renderer that is wrong.  At
worst, adding area=yes
is superfluous if everything (renderers, editors, etc.) already treat that
object as an area.


> So, I'd like to emphasize:
>
>   * The tagging should address protection status and purpose, not what
> level of government (or private agency, or indigenous community)
> manages it.
>

Seems reasonable.  Another tag could be introduced if it were ever
necessary to
state the level of organization that manages it.

  * The purpose should be of a sufficiently general nature (e.g.
> 'recreation') that a typical state park can be preserved as a single
> named entity.
>

Ummm, see Pembrokeshire Coast National Park I gave a link for above.  It
has towns and
cities in it.  I doubt you could generalize that sufficiently well.

  * If the new tag requires a database reload to become a polygon,
> then it should not conflict with the existing tagging on typical state
> parks. If the scheme punishes mappers by failing to render correctly
> tagged features while rendering incorrectly tagged ones, it will not
> take off.
>

Not really controversial.  If it breaks things, it won't be used.

The reason for the third bullet is that I understand that a database
> reload incurs a massive disruption to operations and can be done only
> for extraordinary reasons.


Yeah, that's a problem.  But that's what area=yes is for.  It may not be
what it was intended
to be for, some might consider it a misuse or abuse of tagging, but it
works like a duck.

-- 
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190728/dd83743f/attachment-0001.html>


More information about the Tagging mailing list