[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