Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Martin Koppenhoefer]

sent from a phone

> On 7. Apr 2020, at 11:41, Andrew Davidson  wrote:
> 
> boundary=national_park is an *existing* tag that is used to tag "a relatively 
> large area of land" that is "set aside for human recreation and enjoyment, as 
> well as the protection of the natural environment and/or cultural heritage of 
> an area". This is not exclusively areas with an IUCN management category of 
> II and, as inspection of the current tagging use shows, is not exclusively 
> used for areas with an IUCN management category of II.


you can not expect the OpenStreetMap definitions to be exhaustive in all 
instances. A boundary=national_park is a protected area that is regarded as 
“national park” in the nation where it is located, it’s implicit even if the 
page isn’t explicitly stating it.

Not all "relatively large areas of land" that are "set aside for human 
recreation and enjoyment, as well as the protection of the natural environment 
and/or cultural heritage of an area" get the national park tag, only those that 
are national parks.

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Martin Koppenhoefer]

sent from a phone

> On 7. Apr 2020, at 09:28, Joseph Eisenberg  wrote:
> 
> But if Wikidata is already storing this info, maybe we don’t need a tag for 
> it?


if the information is useful for us, or maybe even essential to understand the 
nature of the thing, then we should have the information in OpenStreetMap and 
not in a third party db.

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Andrew Davidson]

On 7/4/20 5:27 pm, Joseph Eisenberg wrote:

There is also a third tag: leisure=nature_reserve, which is even more
common, and traditionally has been used for natural conservation areas
which are not National Parks or similar.

Used 110k times:
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dnature_reserve


Just over half of those are dual tagged with either 
boundary=national_park or boundary=protected_area




I don’t expect leisure=nature_reserve or boundary=national_park to
disappear, but we can add additional tags to clarify the category of
nature reserve or protected area


OK, I'm obviously not explaining the problem correctly, so I'll try again.

There currently exists the following tags:

boundary=protected_area
protect_class=2

Which is a conservation area with an IUCN management category of II.

The proposal is to replace protect_class=[0-99] with protection_class=* 
and specifies a series of values to replace the numbers used in 
protect_class.


Rather than specifying a value for protection_class that replaces 
protect_class=2, the proposal is to replace it with 
boundary=national_park. boundary=national_park is an *existing* tag that 
is used to tag "a relatively large area of land" that is "set aside for 
human recreation and enjoyment, as well as the protection of the natural 
environment and/or cultural heritage of an area". This is not 
exclusively areas with an IUCN management category of II and, as 
inspection of the current tagging use shows, is not exclusively used for 
areas with an IUCN management category of II.


So the problem is that the proposal is retrospectively redefining 
boundary=national_park to be a conservation area with an IUCN management 
category of II. Which, given the fact that it has already been used over 
13,000 times, is no the wisest thing to do.


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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

> Currently there are two ways to tag a conservation area:
> boundary=national_park
> or
> boundary=protected_area + protect_class=1 to 7

There is also a third tag: leisure=nature_reserve, which is even more
common, and traditionally has been used for natural conservation areas
which are not National Parks or similar.

Used 110k times:
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dnature_reserve

I don’t expect leisure=nature_reserve or boundary=national_park to
disappear, but we can add additional tags to clarify the category of
nature reserve or protected area

Since a boundary=national_park already includes the term “National
Park” in the value and it can also be tagged with “protection_title”,
the only thing missing is a tag that specifically states the IUCN
category, since protect_class includes other values like 1, 7, 21, 97,
etc, and it appears that many mappers add protect_class without
actually checking the official IUCN category.

I suppose protect_class could be replaced by a new tag like
iucn_category= or iucn_level=, or protect_class be changed to only
include 1a,1b,2,3,4,5,6?

But if Wikidata is already storing this info, maybe we don’t need a tag for it?

— Joseph

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Andrew Davidson]

On 6/4/20 9:59 pm, Kevin Kenny wrote:

Can we work around the problem simply by allowing 'protection_class'
to apply to 'boundary=national_park' as well as
'boundary=protected_area' and asserting that the default value of
'protection_class' for 'national_park' shall be assumed to be 2
(surely the plurality, if not the majority, of the areas listed
above)?  


Currently there are two ways to tag a conservation area:

boundary=national_park

or

boundary=protected_area
protect_class=1 to 7

The first is generic, the second is specific as to what level of 
conservation an area has.



I would have assumed that if you were proposing to replace the class 
numbers with phrases then you'd just create a phrase for class 2, rather 
than trying to redefine an existing tag.


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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

> one tag is supported for displaying "one kind of thing"

That's not at all the same as "One feature, one OSM element".

The basic principle is that you don't create 2 different database
objects for the same thing: you don't map a single school as a node
and as an area (closed way) around the node.

Similarly, it's a good idea to add only one main feature tag to a
database object.

While some mappers like to save time by adding barrier=hedge to an
amenity=school closed way, this makes it ambiguous: is the hedge an
area or a line? If there is a name, is it the name of the hedge or the
name of the school? A human can easily pick the right answer, but
computers are not so good at this.

-- Joseph Eisenberg

On 4/6/20, Martin Koppenhoefer  wrote:
> Am Mo., 6. Apr. 2020 um 14:00 Uhr schrieb Kevin Kenny <
> kevin.b.ke...@gmail.com>:
>
>> That would also allow us to address Joseph Eisenberg's objection (in
>> the talk page on the WIki) that the proposal violates the 'one object,
>> one tag' principle.
>
>
>
> there is no such principle (AFAIK a principle like this is tried to adhere
> to in OSM-Carto, where they try that one tag is supported for displaying
> "one kind of thing" (and to which there is at least the exception of
> highway=footway and highway=path with foot=designated, etc.). But this
> isn't a general OSM principle (where we also generally try to avoid
> different tags with the same meaning, but accept their creation if there
> are reasons).
> The principle in OSM tagging is "One feature, one OSM element", and it will
> always work out if you apply the "correct interpretation", because the real
> world doesn't have "features", they come into existence with us defining
> what a feature is. E.g. a School delimited by a fence could be seen as 2
> features: a school and a fence, or it could be seen as one feature, a
> fenced off school.
>
> Cheers
> Martin
>

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Martin Koppenhoefer]

Am Mo., 6. Apr. 2020 um 14:00 Uhr schrieb Kevin Kenny <
kevin.b.ke...@gmail.com>:

> That would also allow us to address Joseph Eisenberg's objection (in
> the talk page on the WIki) that the proposal violates the 'one object,
> one tag' principle.



there is no such principle (AFAIK a principle like this is tried to adhere
to in OSM-Carto, where they try that one tag is supported for displaying
"one kind of thing" (and to which there is at least the exception of
highway=footway and highway=path with foot=designated, etc.). But this
isn't a general OSM principle (where we also generally try to avoid
different tags with the same meaning, but accept their creation if there
are reasons).
The principle in OSM tagging is "One feature, one OSM element", and it will
always work out if you apply the "correct interpretation", because the real
world doesn't have "features", they come into existence with us defining
what a feature is. E.g. a School delimited by a fence could be seen as 2
features: a school and a fence, or it could be seen as one feature, a
fenced off school.

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

It's true that not all "National Parks" are IUCN level 2, though most
IUCN level 2 features appear to be National Parks, and of the 1700
boundary=national_park features which are also tagged with
protect_class, 3/4 are protect_class=2, only 1 out of 4 has a
different number. See http://overpass-turbo.eu/s/SsZ and
http://overpass-turbo.eu/s/St0.

The wiki page mentions that some other features, like Natural
Monuments and Wilderness areas, are currently tagged as
boundary=national_park, since that was the only original tag for such
areas.

So some features would need to be re-tagged as boundary=protected_area
if we are going to use boundary=national_park for just National Parks,
but this will be much less retagging than attempting to change all
boundary=national_park features to =protected_area + the right IUCN
category.

If someone wants to directly tag the IUCN category for different
areas, they could use a more specific tag like "iucn_cateogry=" with
only the actual IUCN levels (1a, 1b, 2 - 6), though it seems like
Wikidata might be a better place to record such details which have to
be imported from outside datasets.
https://en.wikipedia.org/wiki/IUCN_protected_area_categories

-- Joseph Eisenberg

On 4/6/20, Kevin Kenny  wrote:
> On Mon, Apr 6, 2020 at 6:37 AM Andrew Davidson  wrote:
>>
>> On 6/4/20 9:23 am, Joseph Eisenberg wrote:
>> > The only thing that the proposal page still needs is a couple more
>> > detailed definitions for some of the tags.
>>
>> Maybe not. A quick read finds this statement:
>>
>> protect_class=2 will be tagged as boundary=national_park (de facto)
>>
>> This is a problem because boundary=national_park already exists as a
>> generic tag for a conservation area. A quick survey of all of the
>> existing boundary=national_park with a wikidata link finds the following
>> range of IUCN Protected Area Categories:
>>
>> Class  Count
>> IA   95
>> IB   70
>> II  848
>> III  74
>> IV  277
>> V   234
>> VI  159
>> Total  1757
>>
>> So less than 50% of "National Parks" are Cat II.
>>
>> I would suggest adding protection_class=national_park and dropping the
>> suggestion of using boundary=national_park.
>
> [A side point:]
> While I regard IUCN as a fine authority for the definition of the
> protection categories, I have found it to be considerably less useful
> for the application of the definition. For instance, in my home state
> of New York, all Wilderness Areas are tagged as category VI on IUCN's
> site. This is surely incorrect; the language that establishes them is
> nearly identical to the parallel language in the (US Federal)
> Wilderness Act. Motorized travel, harvesting of trees, bicycles, the
> erection of permanent structures (there is an exemption for certain
> improvements to trails and campsites to protect the rest of the area
> from hikers), all are strictly forbidden. Areas protected by NGO's
> (e.g., Nature Conservancy, Open Space Institute, Ducks Unlimited) and
> land trusts are not listed at all.
>
> [A stronger point:]
> I agree with you that boundary=national_park presents us with an
> awkward problem: what does it mean? It's a tag that's been around for
> a long time, and there are over a thousand objects that bear it. If it
> simply means that an area has the phrase, "National Park" (in the
> local language) somewhere in its name, it's pretty redundant, and
> fails to cover features that are national parks in structure and
> function but named differently. If it simply means 'category II
> protected area,' then it's surely redundant, but furthermore, half of
> the ones we have are mistagged. Perhaps most awkwardly, once we've
> chosen to use the tag, 'boundary=national_park', then
> 'boundary=protected_area' is no longer available to us.
>
> Can we work around the problem simply by allowing 'protection_class'
> to apply to 'boundary=national_park' as well as
> 'boundary=protected_area' and asserting that the default value of
> 'protection_class' for 'national_park' shall be assumed to be 2
> (surely the plurality, if not the majority, of the areas listed
> above)?  That could also allow us to choose, for example, 1b for a
> national park that is all wilderness, or 6 for one of the porous
> national parks in the UK, where most of the land is in private hands
> and people continue to live and work inside a park's borders (albeit
> under severe constraints as to the uses to which the land may be put).
> We could also then state that 'boundary=national_park' should be used
> in preference to 'boundary=protected_area' where it applies.
>
> That would also allow us to address Joseph Eisenberg's objection (in
> the talk page on the WIki) that the proposal violates the 'one object,
> one tag' principle. We could retain established tagging for such
> things as 'leisure=nature_reserve' or 'landuse=recreation_ground'
> while still indicating that the features enjoy a particular legal
> protection, by augmenting the tagging with a 'protection_class'.

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

On Mon, Apr 6, 2020 at 6:37 AM Andrew Davidson  wrote:
>
> On 6/4/20 9:23 am, Joseph Eisenberg wrote:
> > The only thing that the proposal page still needs is a couple more
> > detailed definitions for some of the tags.
>
> Maybe not. A quick read finds this statement:
>
> protect_class=2 will be tagged as boundary=national_park (de facto)
>
> This is a problem because boundary=national_park already exists as a
> generic tag for a conservation area. A quick survey of all of the
> existing boundary=national_park with a wikidata link finds the following
> range of IUCN Protected Area Categories:
>
> Class  Count
> IA   95
> IB   70
> II  848
> III  74
> IV  277
> V   234
> VI  159
> Total  1757
>
> So less than 50% of "National Parks" are Cat II.
>
> I would suggest adding protection_class=national_park and dropping the
> suggestion of using boundary=national_park.

[A side point:]
While I regard IUCN as a fine authority for the definition of the
protection categories, I have found it to be considerably less useful
for the application of the definition. For instance, in my home state
of New York, all Wilderness Areas are tagged as category VI on IUCN's
site. This is surely incorrect; the language that establishes them is
nearly identical to the parallel language in the (US Federal)
Wilderness Act. Motorized travel, harvesting of trees, bicycles, the
erection of permanent structures (there is an exemption for certain
improvements to trails and campsites to protect the rest of the area
from hikers), all are strictly forbidden. Areas protected by NGO's
(e.g., Nature Conservancy, Open Space Institute, Ducks Unlimited) and
land trusts are not listed at all.

[A stronger point:]
I agree with you that boundary=national_park presents us with an
awkward problem: what does it mean? It's a tag that's been around for
a long time, and there are over a thousand objects that bear it. If it
simply means that an area has the phrase, "National Park" (in the
local language) somewhere in its name, it's pretty redundant, and
fails to cover features that are national parks in structure and
function but named differently. If it simply means 'category II
protected area,' then it's surely redundant, but furthermore, half of
the ones we have are mistagged. Perhaps most awkwardly, once we've
chosen to use the tag, 'boundary=national_park', then
'boundary=protected_area' is no longer available to us.

Can we work around the problem simply by allowing 'protection_class'
to apply to 'boundary=national_park' as well as
'boundary=protected_area' and asserting that the default value of
'protection_class' for 'national_park' shall be assumed to be 2
(surely the plurality, if not the majority, of the areas listed
above)?  That could also allow us to choose, for example, 1b for a
national park that is all wilderness, or 6 for one of the porous
national parks in the UK, where most of the land is in private hands
and people continue to live and work inside a park's borders (albeit
under severe constraints as to the uses to which the land may be put).
We could also then state that 'boundary=national_park' should be used
in preference to 'boundary=protected_area' where it applies.

That would also allow us to address Joseph Eisenberg's objection (in
the talk page on the WIki) that the proposal violates the 'one object,
one tag' principle. We could retain established tagging for such
things as 'leisure=nature_reserve' or 'landuse=recreation_ground'
while still indicating that the features enjoy a particular legal
protection, by augmenting the tagging with a 'protection_class'.
'Boundary=protected_area' could then be reserved for the features for
which no existing tagging applies. The inapplicability can come about
for numerous reasons. For instance, 'protected_area' may become the
unifying tag because the protection status is the only salient
feature, or because there is no existing tagging that applies well, or
because the area admits of mixed land uses that share a common
boundary and name.


-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

Andrew, would you please repeat this analysis with all features tagged
"protect_class=2" which have a wikidata tag?

I suspect that many of those will not match according to Wikidata.

On 4/6/20, Andrew Davidson  wrote:
> On 6/4/20 9:23 am, Joseph Eisenberg wrote:
>> The only thing that the proposal page still needs is a couple more
>> detailed definitions for some of the tags.
>
> Maybe not. A quick read finds this statement:
>
> protect_class=2 will be tagged as boundary=national_park (de facto)
>
> This is a problem because boundary=national_park already exists as a
> generic tag for a conservation area. A quick survey of all of the
> existing boundary=national_park with a wikidata link finds the following
> range of IUCN Protected Area Categories:
>
> Class  Count
> IA   95
> IB   70
> II  848
> III  74
> IV  277
> V   234
> VI  159
> Total  1757
>
> So less than 50% of "National Parks" are Cat II.
>
> I would suggest adding protection_class=national_park and dropping the
> suggestion of using boundary=national_park.
>
>
> ___
> 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 - protection_class=* (Words, not numeric codes)

[Andrew Davidson]

On 6/4/20 9:23 am, Joseph Eisenberg wrote:

The only thing that the proposal page still needs is a couple more
detailed definitions for some of the tags.


Maybe not. A quick read finds this statement:

protect_class=2 will be tagged as boundary=national_park (de facto)

This is a problem because boundary=national_park already exists as a 
generic tag for a conservation area. A quick survey of all of the 
existing boundary=national_park with a wikidata link finds the following 
range of IUCN Protected Area Categories:


Class  Count
IA   95
IB   70
II  848
III  74
IV  277
V   234
VI  159
Total  1757

So less than 50% of "National Parks" are Cat II.

I would suggest adding protection_class=national_park and dropping the 
suggestion of using boundary=national_park.



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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

Does the current version look any better?  Obviously, once we're
seriously stitching things into the Wiki, we'll need to make
individual pages with titles like 'Key:protection_class=recreation',
but of course it's easier to have it all in one place for now.


On Sun, Apr 5, 2020 at 7:24 PM Joseph Eisenberg
 wrote:
>
> The only thing that the proposal page still needs is a couple more
> detailed definitions for some of the tags.
>
> The ones based on IUCN levels already have a fairly good description.
>
> But protection_class=recreation should be clarified - what exactly is
> protected here, and what sort of recreation are we talking about? It
> should be clear how this is different than a leisure=recreation_ground
> or sports_centre or =park.
>
> The tags protection_class=water, protection_class=culture,  and
> protection_class=hazard might need slightly improved definitions too.
>
> Besides that, everything looks pretty good.
>
> -- Joseph Eisenberg
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

The only thing that the proposal page still needs is a couple more
detailed definitions for some of the tags.

The ones based on IUCN levels already have a fairly good description.

But protection_class=recreation should be clarified - what exactly is
protected here, and what sort of recreation are we talking about? It
should be clear how this is different than a leisure=recreation_ground
or sports_centre or =park.

The tags protection_class=water, protection_class=culture,  and
protection_class=hazard might need slightly improved definitions too.

Besides that, everything looks pretty good.

-- Joseph Eisenberg

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[François Lacombe]

Hi,

+1 with Joseph, proposed values are more usable than digits.

Le dim. 5 avr. 2020 à 20:02, Kevin Kenny  a écrit :

> I'm a little intimidated by the process, particularly the
> administration of the vote (Who's a qualified elector? Who can serve
> as scrutineer?) and the need to stitch the result into the Wiki.  Some
> of what's needed for the latter seems to require knowledge of the
> Wiki's templating conventions, which appear to be obscurely documented
> at best, and with which I'm unfamiliar. (Also, it brings up unpleasant
> memories. I've burnt my fingers on Wikipedia in the past.)
>

No problem : voting is a pretty simple phase :
Open the vote, announce it on mailing list (here), wait 15 days to have
some opinions and close it
Any wiki user can vote, cons vote should come with a little explanations.
If you get at least 74% of pros (without counting abstain as cons), the
proposal is adopted and cleanup can begin. Anyone can help you to move what
is proposed in tagging pages.
It is recommended to prepare this cleanup with a section like this one,
showing affected pages and replaced keys (if applicable) :
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management#Edition_management

We are here to help if needed, keep going !

All the best

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

I suppose, now.  It seems to be gaining some traction, at long last.
When I floated it, it was not nearly as popular, largely because of
the way it tied into the flood of words exchanged between Adamant(some
digits) and stevea in various media. The discussion at the time shed
more heat than light.

I'm a little intimidated by the process, particularly the
administration of the vote (Who's a qualified elector? Who can serve
as scrutineer?) and the need to stitch the result into the Wiki.  Some
of what's needed for the latter seems to require knowledge of the
Wiki's templating conventions, which appear to be obscurely documented
at best, and with which I'm unfamiliar. (Also, it brings up unpleasant
memories. I've burnt my fingers on Wikipedia in the past.)

I've been hoping against hope that someone will help me with the
mechanics. I'm considerably better at data modeling than I am at
Wiki-gnoming!

On Sun, Apr 5, 2020 at 12:39 AM Joseph Eisenberg
 wrote:
>
> Kevin,
>
> Would you have time to move this proposal forward?
>
> I've been looking at the protected_area classes, and there are several
> that are confusing and overlap with other features, especially
> protected_class = 7, 19, 21, 29, 97, 98, 99.
>
> And several are duplicates of more common tags:
>
> boundary=national_park (de facto) for protect_class=2
>
> boundary=aboriginal_lands (approved) for protect_class=24
>
> landuse=military + military= for protect_class=25
>
> I like the way your proposal has suggested changing these all to more
> memorable and intelligible words as values of "protection_class=",
> like "protection_class=recreation" instead of "21"
>
> -- Joseph Eisenberg
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

Kevin,

Would you have time to move this proposal forward?

I've been looking at the protected_area classes, and there are several
that are confusing and overlap with other features, especially
protected_class = 7, 19, 21, 29, 97, 98, 99.

And several are duplicates of more common tags:

boundary=national_park (de facto) for protect_class=2

boundary=aboriginal_lands (approved) for protect_class=24

landuse=military + military= for protect_class=25

I like the way your proposal has suggested changing these all to more
memorable and intelligible words as values of "protection_class=",
like "protection_class=recreation" instead of "21"

-- Joseph Eisenberg

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

On Thu, Aug 29, 2019 at 1:10 PM Paul Allen  wrote:
> Yes, it is indeed complicated.  But it definitely is a national park.
> https://en.wikipedia.org/wiki/Pembrokeshire_Coast_National_Park
> and https://www.pembrokeshirecoast.wales/default.asp?PID=161
> It may include things that many wouldn't associate with a national
> park, but it's a national park.  Not just in name but also legally.

Oh wait a minute, it was *you* that had brought up Pembrokeshire
Coast. Sorry! Richard Fairhurst also brought up the Broads as a
complicated example. (He'd been cycling one summer in the Catskill
Park, and approved of the  'boundary=national_park' as "quacks like a
duck" even though the Catskill Park is definitely not a National
Park.)

>> 'If it looks like a duck and quacks like a duck but needs batteries,
>> you probably have the wrong abstraction.' - B. Liskov
>
> But we'll tag it as a duck anyway.  Because this is OSM.

And because mapping is a human endeavour, and humans delight in
contriving things that break abstractions.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Paul Allen]

On Thu, 29 Aug 2019 at 17:50, Kevin Kenny  wrote:

(Earlier in the thread, I mentioned tagging the Catskill and
> Adirondack Parks in New York as 'national_park' and not apologizing.
> Someone replied to me giving Pembrokeshire Coast National Park as a UK
> precedent for a 'national park that isnt a National Park, and it's
> complicated.')
>

Yes, it is indeed complicated.  But it definitely is a national park.
https://en.wikipedia.org/wiki/Pembrokeshire_Coast_National_Park
and https://www.pembrokeshirecoast.wales/default.asp?PID=161
It may include things that many wouldn't associate with a national
park, but it's a national park.  Not just in name but also legally.

'If it looks like a duck and quacks like a duck but needs batteries,
> you probably have the wrong abstraction.' - B. Liskov
>

But we'll tag it as a duck anyway.  Because this is OSM.

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

On Thu, Aug 29, 2019 at 12:06 PM Paul Allen  wrote:
>> Since the values are keywords, they should be endlessly expandable.
>> Constraining ourselves to the IUCN numeric codes is one of the things
>> that got us into this particular mess in the first place. I intend the
>> set of keywords to be open-ended, but urge discipline so that data
>> consumers don't need to deal with hundreds of variants for the details
>> of each jurisdiction's law. This categorization should give the 'broad
>> strokes'.
>
> I just thought I'd let you know how broad some of those strokes will have to
> be. :)

Uhm, I already knew that.  :)

Some of the legal classifications in some jurisdictions don't actually
inform about what sort of resource is being protected. In the US,
'State Park' often flaas under a single establishing law, and doesn't
inform about the specific protection, which can be anything from a
wilderness area to an urban swimming beach or a public golf course -
or even a brownfield (https://www.openstreetmap.org/relation/6539925
and https://www.openstreetmap.org/way/439630427; oddly appropriate
somehow!). Protection status is just as weird and fragmentary in the
US as it is in the UK, but there has to be *something* to help a
general-interest data consumer sort things out. I assure you that I
deal with suppressing the complexity all the time.
https://www.dec.ny.gov/lands/7811.html is only a *partial* list of the
sorts of public lands that I encounter. Those are adminstered by the
New York State Department of Environmental Protection. There are
others administred by Parks, Recreation and Historic Preservation, or
by other state departments, or the Federal government, or local
governmnents, or NGO's. I'm trying to chart the middle course of
'useful although necessarily imprecise abstraction'.

(Earlier in the thread, I mentioned tagging the Catskill and
Adirondack Parks in New York as 'national_park' and not apologizing.
Someone replied to me giving Pembrokeshire Coast National Park as a UK
precedent for a 'national park that isnt a National Park, and it's
complicated.')

'If it looks like a duck and quacks like a duck but needs batteries,
you probably have the wrong abstraction.' - B. Liskov

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Paul Allen]

On Thu, 29 Aug 2019 at 16:31, Kevin Kenny  wrote:

> Site of Special Scientific Interest.
> Does that actually specify what sort of protection the site enjoys?
>

Yes and no.  It's complicated. :)

https://en.wikipedia.org/wiki/Site_of_Special_Scientific_Interest is an
overview.
As applied to England (Scotland, Wales, etc. are somewhat different)
https://www.gov.uk/guidance/protected-areas-sites-of-special-scientific-interest

It's possible you could shoehorn SSSIs into an existing class or classes.


> Area of Outstanding Natural Beauty.
> protection_class(or protection_category per the earlier
> discussion)=landscape?
>

Possibly.  Probably.  Maybe. :)

>  World Heritage
> > Site and World Heritage Site Arcs of View.  Registered Historic
> Landscape.  Protected
> > Wreck.  There are also scheduled monuments, but they're generally
> man-made and
> > dealt with by heritage=*.
>
> Most of these would fall under 'cultural', I think - they're not
> protecting a natural condition of the site but rather its cultural
> significance.
>

The cultural significance can be one reason it is categorized as such, but
the other is
its natural beauty/aesthetic importance.  Either way, it's legally
protected (otherwise
anyone could come along and trash it, ruining its status).  See
https://en.wikipedia.org/wiki/World_Heritage_Site


Since the values are keywords, they should be endlessly expandable.
> Constraining ourselves to the IUCN numeric codes is one of the things
> that got us into this particular mess in the first place. I intend the
> set of keywords to be open-ended, but urge discipline so that data
> consumers don't need to deal with hundreds of variants for the details
> of each jurisdiction's law. This categorization should give the 'broad
> strokes'.
>

I just thought I'd let you know how broad some of those strokes will have to
be. :)

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

On Thu, Aug 29, 2019 at 9:17 AM Paul Allen  wrote:
> Here are some other UK types that occur to me.  Some already have other ways 
> of
> being mapped.  Some may fit in with categories/classes/whatevers you already
> have.  I don't insist  that your proposal deals with all of them right now 
> (you
> already have enough to be going on with) but it would be nice if your proposal
> doesn't make it impossible to add them, cleanly, at a later date.  Don't paint
> yourself into any corners if you can avoid it. :)

> Site of Special Scientific Interest.
Does that actually specify what sort of protection the site enjoys?
This might have to be handled case by case. I can think of similar
things near me, and they range from 'strict nature reserve' (the
Rosendale bat caves, and one or two of the 'Estuarine Reserach
Reserves' and 'Biological Research Stations') to 'area with
sustainable use of natural resources' ( the title,'Demonstration
Forest' is one example.)

> Area of Outstanding Natural Beauty.
protection_class(or protection_category per the earlier discussion)=landscape?

>  World Heritage
> Site and World Heritage Site Arcs of View.  Registered Historic Landscape.  
> Protected
> Wreck.  There are also scheduled monuments, but they're generally man-made and
> dealt with by heritage=*.

Most of these would fall under 'cultural', I think - they're not
protecting a natural condition of the site but rather its cultural
significance.

Since the values are keywords, they should be endlessly expandable.
Constraining ourselves to the IUCN numeric codes is one of the things
that got us into this particular mess in the first place. I intend the
set of keywords to be open-ended, but urge discipline so that data
consumers don't need to deal with hundreds of variants for the details
of each jurisdiction's law. This categorization should give the 'broad
strokes'.



We also have 'protection_title' and 'related_law' available to let us
link to finer details. I already use those in New York. For example,we
have 'Wilderness Area', 'Wild Forest', 'Canoe Area' and 'Primitive
Area' (plus an anomalous 'Forest Preserve Detached Parcel') that are
all effectively 'wilderness'-level protection but with various subtle
differences in the regulations and management strategy that concern me
as an off-trail hiker, sometime trail maintainer, and protection
advocate but would be lost on most users.

For instance, 'Wild Forest' allows some 'highway=track', generally
'tracktype=grade3' and worse, and there's a 'Motor Access Program for
Persons With Disabilities'. I handle that by tagging the tracks
'motor_vehicle=official;disabled'. It also generally allows trail
crews to work with power tools such as chainsaws, while in Wilderness,
trail maintenance is ordinarily done with hand tools only, and any
motor, even a chainsaw, brush hog, or weed whacker, requires special
permission. I don't find that distinction to be worth calling out at
this level of detail.

Similarly, 'Primitive Area' translates to 'the management intention is
wilderness-level protection, but there is some nonconformant fixed
asset for which no definitive timetable can be set for removal.' I can
discourse endlessly on the politics of specific Primitive Areas, and
very few people would care.

I also stretch 'wilderness' to include a few things like 'Primitive
Bicycle Corridor' (a narrow strip carved out of a wilderness area that
effectively has the same management except that it's permissible to
harden a trail sufficiently to accommodate a mountain bike rider).

To the level of granularity contemplated here, all of these are
'wilderness'. I have the protection title and legal citation available
if I need them.


-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Paul Allen]

On Thu, 29 Aug 2019 at 00:05, Kevin Kenny  wrote:

>
> I _am_ tempted to change the name to 'protection_category' because
> that's IUCN's term,


No objections from me.


> and then discuss on the Wiki that 'recreation',
> 'culture', and 'hazard' expand upon the IUCN vocabulary to encompass
> types of protection that the International Union for the Conservation
> of *Nature* does not recognize (these protections, in general, apply
> to sites that are substantially altered from a natural state and for
> which returning them to a natural state may not be an objective).
>

Here are some other UK types that occur to me.  Some already have other
ways of
being mapped.  Some may fit in with categories/classes/whatevers you already
have.  I don't insist  that your proposal deals with all of them right now
(you
already have enough to be going on with) but it would be nice if your
proposal
doesn't make it impossible to add them, cleanly, at a later date.  Don't
paint
yourself into any corners if you can avoid it. :)

Site of Special Scientific Interest.  Area of Outstanding Natural Beauty.
World Heritage
Site and World Heritage Site Arcs of View.  Registered Historic Landscape.
Protected
Wreck.  There are also scheduled monuments, but they're generally man-made
and
dealt with by heritage=*.

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Warin]

On 29/08/19 09:21, François Lacombe wrote:


Le jeu. 29 août 2019 à 01:01, Graeme Fitzpatrick 
mailto:graemefi...@gmail.com>> a écrit :



I've just had a quick play on TagInfo & protect_class &
protection_title, plus a couple of others, all refer to protected
areas of one type or another


Current usage on OSM is clear and I don't question this
This proposal is an opportunity to be sure we're choosing the most 
appropriate word regarding what the target is.


 How about reserving IP_class or IP_protection? Would seem to
cover it nicely (especially if they're not actually used!)


According to what Paul said, ingress_protection would be better. 
ip_protection is redundant (p of protection + "protection")


Then we shouldn't have simple protection=* for this proposal but 
_protection too.

As N of IUCN means Nature, what about nature_protection?


+1 for nature_protection. Says what it is?




Le jeu. 29 août 2019 à 01:05, Kevin Kenny > a écrit :



If people insist, I'd go to 'protected_area:category', but I consider
that to be rather too verbose, and I'm not sure that it's worth it to
avoid the minimal risk of namespace pollution.


Effort is appreciable, but there is no need to introduce namespace here
Currently I'd be in favour of removing at least _class or _type 
suffixes as it doesn't bring additional information.


Class and type add nothing, don't use them.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[François Lacombe]

Le jeu. 29 août 2019 à 01:01, Graeme Fitzpatrick  a
écrit :

>
> I've just had a quick play on TagInfo & protect_class & protection_title,
> plus a couple of others, all refer to protected areas of one type or another
>

Current usage on OSM is clear and I don't question this
This proposal is an opportunity to be sure we're choosing the most
appropriate word regarding what the target is.


>  How about reserving IP_class or IP_protection? Would seem to cover it
> nicely (especially if they're not actually used!)
>

According to what Paul said, ingress_protection would be better.
ip_protection is redundant (p of protection + "protection")

Then we shouldn't have simple protection=* for this proposal but
_protection too.
As N of IUCN means Nature, what about nature_protection?

Le jeu. 29 août 2019 à 01:05, Kevin Kenny  a
écrit :

>
> If people insist, I'd go to 'protected_area:category', but I consider
> that to be rather too verbose, and I'm not sure that it's worth it to
> avoid the minimal risk of namespace pollution.


Effort is appreciable, but there is no need to introduce namespace here
Currently I'd be in favour of removing at least _class or _type suffixes as
it doesn't bring additional information.

All the best

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

Re: > change the key to 'protection_category='

That would be fine.

Re: > 'protected_area:category'

No thank you; no need to add :type or :category suffixes to keys. You
could use 'protected_area=*' as the key. It has the disadvantage of
already being used a couple of hundred times, but the current values
are not terrible:
https://taginfo.openstreetmap.org/keys/protected_area

But overall, I think protection_class=* is fine.

On 8/29/19, Kevin Kenny  wrote:
> On Wed, Aug 28, 2019 at 6:21 PM Paul Allen  wrote:
>> To be honest, I'd not expect a national park to be protected from liquid
>> or particulate ingress,
>> nor an electrical enclosure to impose restrictions on building houses
>> within it.  Nor do I expect
>> even micro-mappers to document the IP rating of electrical enclosures they
>> map.  The only
>> thing we really need to worry about is namespace collision, and that's
>> usually dealt with by
>> a first-come/first-served approach.
>>
>>> Let's see if Kevin wishes to take care of this
>>
>> If he can, that would be good.  If he can't, then anyone who needs to map
>> the International
>> Protection rating of electrical enclosures will have to come up with a
>> different tag. :)
>
> As Paul observes, the collision seems pretty far-fetched. I'm sure
> that there are all sorts of non-geographic things that are protected
> from something or other and may admit of classes of protection. I
> can't imagine any of those being associated with a
> boundary=protected_area (or national_park, or aboriginal_lands), and I
> don't intend 'protection_class' to stand alone.
>
> I _am_ tempted to change the name to 'protection_category' because
> that's IUCN's term, and then discuss on the Wiki that 'recreation',
> 'culture', and 'hazard' expand upon the IUCN vocabulary to encompass
> types of protection that the International Union for the Conservation
> of *Nature* does not recognize (these protections, in general, apply
> to sites that are substantially altered from a natural state and for
> which returning them to a natural state may not be an objective).
>
> If people insist, I'd go to 'protected_area:category', but I consider
> that to be rather too verbose, and I'm not sure that it's worth it to
> avoid the minimal risk of namespace pollution.
>
> --
> 73 de ke9tv/2, Kevin
>
> ___
> 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 - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

On Wed, Aug 28, 2019 at 6:21 PM Paul Allen  wrote:
> To be honest, I'd not expect a national park to be protected from liquid or 
> particulate ingress,
> nor an electrical enclosure to impose restrictions on building houses within 
> it.  Nor do I expect
> even micro-mappers to document the IP rating of electrical enclosures they 
> map.  The only
> thing we really need to worry about is namespace collision, and that's 
> usually dealt with by
> a first-come/first-served approach.
>
>> Let's see if Kevin wishes to take care of this
>
> If he can, that would be good.  If he can't, then anyone who needs to map the 
> International
> Protection rating of electrical enclosures will have to come up with a 
> different tag. :)

As Paul observes, the collision seems pretty far-fetched. I'm sure
that there are all sorts of non-geographic things that are protected
from something or other and may admit of classes of protection. I
can't imagine any of those being associated with a
boundary=protected_area (or national_park, or aboriginal_lands), and I
don't intend 'protection_class' to stand alone.

I _am_ tempted to change the name to 'protection_category' because
that's IUCN's term, and then discuss on the Wiki that 'recreation',
'culture', and 'hazard' expand upon the IUCN vocabulary to encompass
types of protection that the International Union for the Conservation
of *Nature* does not recognize (these protections, in general, apply
to sites that are substantially altered from a natural state and for
which returning them to a natural state may not be an objective).

If people insist, I'd go to 'protected_area:category', but I consider
that to be rather too verbose, and I'm not sure that it's worth it to
avoid the minimal risk of namespace pollution.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Graeme Fitzpatrick]

On Thu, 29 Aug 2019 at 08:21, Paul Allen  wrote:

> On Wed, 28 Aug 2019 at 22:50, François Lacombe 
> wrote:
>
>> Thats a detail, official document stands for International Protection
>> https://texa-co.ir/wp-content/uploads/2017/04/IEC-60529.pdf (see §4 page
>> 18)
>>
>
> You're right.  I've only ever encountered "IP" expanded as Ingress
> Protection, which makes
> sense.
>

It requires at least a strong context to not be confused with any other
>> protection classification system.
>>
>
> To be honest, I'd not expect a national park to be protected from liquid
> or particulate ingress,
> nor an electrical enclosure to impose restrictions on building houses
> within it.  Nor do I expect
> even micro-mappers to document the IP rating of electrical enclosures they
> map.  The only
> thing we really need to worry about is namespace collision, and that's
> usually dealt with by
> a first-come/first-served approach.
>

I've just had a quick play on TagInfo & protect_class & protection_title,
plus a couple of others, all refer to protected areas of one type or another


>  If he can't, then anyone who needs to map the International
> Protection rating of electrical enclosures will have to come up with a
> different tag. :)
>

How about reserving IP_class or IP_protection? Would seem to cover it
nicely (especially if they're not actually used!)

Thanks

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

Re: “anyone who needs to map the International Protection rating of
electrical enclosures will have to come up with a different tag”

+1

No need to worry about this.

Joseph

On Thu, Aug 29, 2019 at 7:21 AM Paul Allen  wrote:

> On Wed, 28 Aug 2019 at 22:50, François Lacombe 
> wrote:
>
>>
>> Le mer. 28 août 2019 à 19:09, Paul Allen  a écrit :
>>
>>>
>>> Nope, Ingress Protection.  It's an international standard, though.
>>>
>> Thats a detail, official document stands for International Protection
>> https://texa-co.ir/wp-content/uploads/2017/04/IEC-60529.pdf (see §4 page
>> 18)
>>
>
> You're right.  I've only ever encountered "IP" expanded as Ingress
> Protection, which makes
> sense.  Now I've done some digging, I found the Wikipedia talk page where
> they suspect
> the authors of the standard made an error.  One commenter pointed out that
> "International
> Protection" would be about preventing warfare.  Another commenter said
> that when he
> worked on translating a standard he encountered many errors.  Even so, the
> official
> document covering testing of enclosures for the degree of protection they
> offer to the
> ingress of liquids and particulates says, as an aside, that IP stands for
> "International
> Protection" and not the "Ingress Protection" that would make more sense.
>
> If we can avoid confusion, we should.  I'm not sure that this does.
>>>
>> It requires at least a strong context to not be confused with any other
>> protection classification system.
>>
>
> To be honest, I'd not expect a national park to be protected from liquid
> or particulate ingress,
> nor an electrical enclosure to impose restrictions on building houses
> within it.  Nor do I expect
> even micro-mappers to document the IP rating of electrical enclosures they
> map.  The only
> thing we really need to worry about is namespace collision, and that's
> usually dealt with by
> a first-come/first-served approach.
>
> Let's see if Kevin wishes to take care of this
>>
>
> If he can, that would be good.  If he can't, then anyone who needs to map
> the International
> Protection rating of electrical enclosures will have to come up with a
> different tag. :)
>
> --
> 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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Paul Allen]

On Wed, 28 Aug 2019 at 22:50, François Lacombe 
wrote:

>
> Le mer. 28 août 2019 à 19:09, Paul Allen  a écrit :
>
>>
>> Nope, Ingress Protection.  It's an international standard, though.
>>
> Thats a detail, official document stands for International Protection
> https://texa-co.ir/wp-content/uploads/2017/04/IEC-60529.pdf (see §4 page
> 18)
>

You're right.  I've only ever encountered "IP" expanded as Ingress
Protection, which makes
sense.  Now I've done some digging, I found the Wikipedia talk page where
they suspect
the authors of the standard made an error.  One commenter pointed out that
"International
Protection" would be about preventing warfare.  Another commenter said that
when he
worked on translating a standard he encountered many errors.  Even so, the
official
document covering testing of enclosures for the degree of protection they
offer to the
ingress of liquids and particulates says, as an aside, that IP stands for
"International
Protection" and not the "Ingress Protection" that would make more sense.

If we can avoid confusion, we should.  I'm not sure that this does.
>>
> It requires at least a strong context to not be confused with any other
> protection classification system.
>

To be honest, I'd not expect a national park to be protected from liquid or
particulate ingress,
nor an electrical enclosure to impose restrictions on building houses
within it.  Nor do I expect
even micro-mappers to document the IP rating of electrical enclosures they
map.  The only
thing we really need to worry about is namespace collision, and that's
usually dealt with by
a first-come/first-served approach.

Let's see if Kevin wishes to take care of this
>

If he can, that would be good.  If he can't, then anyone who needs to map
the International
Protection rating of electrical enclosures will have to come up with a
different tag. :)

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[François Lacombe]

Le mer. 28 août 2019 à 19:09, Paul Allen  a écrit :

> But IP ratings are regarded as environmental protection ratings.  So that
> has the same problem.
> "Environmental protection" can mean "protecting the environment" or
> "protecting things from the
> environment."
>

Seems legit
This will need further thinking, maybe someone else will get the proper key
name


>
> Nope, Ingress Protection.  It's an international standard, though.
>
Thats a detail, official document stands for International Protection
https://texa-co.ir/wp-content/uploads/2017/04/IEC-60529.pdf (see §4 page 18)

If we can avoid confusion, we should.  I'm not sure that this does.
>
It requires at least a strong context to not be confused with any other
protection classification system.

Let's see if Kevin wishes to take care of this

All the best

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Paul Allen]

On Wed, 28 Aug 2019 at 17:47, François Lacombe 
wrote:

>
> As both the topic of the proposal and the IP norm are approximately at the
> same semantic distance of "protection class" term,
>

Reasonable point.

that's why I recommend to move to "environment_protection=*" (or something
> like this) to be more focused on what is actually described.
>

But IP ratings are regarded as environmental protection ratings.  So that
has the same problem.
"Environmental protection" can mean "protecting the environment" or
"protecting things from the
environment."

IP stands for International Protection
>

Nope, Ingress Protection.  It's an international standard, though.

Even if protection class is a misnomer, I find risky to use it as this for
> a completely different topic, that's my 2 cts.All the best
>

If we can avoid confusion, we should.  I'm not sure that this does.

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[François Lacombe]

Le mer. 28 août 2019 à 18:15, Paul Allen  a écrit :

> "Protection class" is something of a misnomer when it comes to IEC 60529,
> since it specifies
> a level of ingress protection (hence the "I" and "P" in the designation)
> against water and
> dust.  It does, as a side-effect, have some bearing on the possibility of
> contact of dangerous
> parts by fingers, but that is largely incidental.  And while you may have
> seen it referred to
> as "protection class" it seems more common to refer to it as "ingress
> protection class."
>

Hi Paul,
As both the topic of the proposal and the IP norm are approximately at the
same semantic distance of "protection class" term, that's why I recommend
to move to "environment_protection=*" (or something like this) to be more
focused on what is actually described.
IP stands for International Protection, which indeed consist in limiting
ingress of foreign object or water in a given enclosure.

Even if protection class is a misnomer, I find risky to use it as this for
a completely different topic, that's my 2 cts.
All the best

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Paul Allen]

On Wed, 28 Aug 2019 at 16:50, François Lacombe 
wrote:

>
> I've noticed a potential conflict with protection degrees defined in IEC
> 60529 norm (IP-XY numbers seen on many electronic appliances), also called
> "protection class".
>

"Protection class" is something of a misnomer when it comes to IEC 60529,
since it specifies
a level of ingress protection (hence the "I" and "P" in the designation)
against water and
dust.  It does, as a side-effect, have some bearing on the possibility of
contact of dangerous
parts by fingers, but that is largely incidental.  And while you may have
seen it referred to
as "protection class" it seems more common to refer to it as "ingress
protection class."

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[François Lacombe]

Hi all,

This proposal sounds good in the field of knowledge it covers and I would
certainly go for it when vote will be open.

I've noticed a potential conflict with protection degrees defined in IEC
60529 norm (IP-XY numbers seen on many electronic appliances), also called
"protection class".
Could you please consider this contribution to RFC please?
https://wiki.openstreetmap.org/wiki/Talk:Proposal:_Named_protection_class_for_protected_areas#Potential_conflict_with_IEC_60529_degrees_of_protection

All the best

François

Le dim. 18 août 2019 à 15:43, Joseph Eisenberg 
a écrit :

> Kevin,
>
> The proposal looks pretty good.
>
> When you've finished editing, please make a clear list off all the
> new, proposed tags, in one place. Also please clarify what pages are
> being edited and if protect_class=* is being deprecated by this
> proposal.
>
> It might make sense to deprecate all values of protect_class other
> than 1 to 6, since those numbers at least correspond to the IUCN
> numbers and most are fairly commonly used, while the higher numbers
> are rare and confusing. Over time, if protection_class becomes much
> more popular, the protect_class:1 to 6 might also become obsolete, but
> for the short term it might be difficult to change them all right
> away.
>
> One thing is that you write in one place that
> protection_class=condition should maybe just be
> protection_class=hazard, to replace the current protect_class=15 and
> 16, "Location Condition" and "Longtime Hazard Area". I think this
> makes sense.
>
> Re: protect_class=24, "Political protection", you might need to talk
> to the folks in Brazil who are using this tag. Not all of them were
> happy with using boundary=aborignal_lands instead, if I recall
> correctly, but perhaps this could change.
>
> Thanks for working on this. I think it's worth doing, since most of
> the protect_class values have never really become used, and their
> meaning is not very clear.
>
> On 8/18/19, Kevin Kenny  wrote:
> > .As has already been discussed at some length in the thread on tagging
> > of State Parks in the US, I've been working on a proposal for a
> > 'protection_class=*' key to replace 'protect_class=*'. It replaces the
> > seven numeric codes from IUCN (plus a zoo of codes that OSM appears to
> > have cut out of whole cloth) with 'protection_object=*', whose values
> > are drawn from a group of word-oriented codes that, it is hoped, will
> > be more mnemonic. (The proposal to describe State Parks as protected
> > areas was reasonably well received except for the issue that it
> > depended on the numeric 'protect_class=*' to describe the protection.)
> >
> > The proposal has now reached a state where I think it can be opened
> > for a formal RFC, and can be found at
> >
> https://wiki.openstreetmap.org/wiki/Proposal:_Named_protection_class_for_protected_areas
> > .
> >
> > Of course, I'll monitor both this list and the talk page for the Wiki
> > page for comments, and try to address whatever comes up.
> > --
> > 73 de ke9tv/2, Kevin
> >
> > ___
> > 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 - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

Kevin,

The proposal looks pretty good.

When you've finished editing, please make a clear list off all the
new, proposed tags, in one place. Also please clarify what pages are
being edited and if protect_class=* is being deprecated by this
proposal.

It might make sense to deprecate all values of protect_class other
than 1 to 6, since those numbers at least correspond to the IUCN
numbers and most are fairly commonly used, while the higher numbers
are rare and confusing. Over time, if protection_class becomes much
more popular, the protect_class:1 to 6 might also become obsolete, but
for the short term it might be difficult to change them all right
away.

One thing is that you write in one place that
protection_class=condition should maybe just be
protection_class=hazard, to replace the current protect_class=15 and
16, "Location Condition" and "Longtime Hazard Area". I think this
makes sense.

Re: protect_class=24, "Political protection", you might need to talk
to the folks in Brazil who are using this tag. Not all of them were
happy with using boundary=aborignal_lands instead, if I recall
correctly, but perhaps this could change.

Thanks for working on this. I think it's worth doing, since most of
the protect_class values have never really become used, and their
meaning is not very clear.

On 8/18/19, Kevin Kenny  wrote:
> .As has already been discussed at some length in the thread on tagging
> of State Parks in the US, I've been working on a proposal for a
> 'protection_class=*' key to replace 'protect_class=*'. It replaces the
> seven numeric codes from IUCN (plus a zoo of codes that OSM appears to
> have cut out of whole cloth) with 'protection_object=*', whose values
> are drawn from a group of word-oriented codes that, it is hoped, will
> be more mnemonic. (The proposal to describe State Parks as protected
> areas was reasonably well received except for the issue that it
> depended on the numeric 'protect_class=*' to describe the protection.)
>
> The proposal has now reached a state where I think it can be opened
> for a formal RFC, and can be found at
> https://wiki.openstreetmap.org/wiki/Proposal:_Named_protection_class_for_protected_areas
> .
>
> Of course, I'll monitor both this list and the talk page for the Wiki
> page for comments, and try to address whatever comes up.
> --
> 73 de ke9tv/2, Kevin
>
> ___
> 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 - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

.As has already been discussed at some length in the thread on tagging
of State Parks in the US, I've been working on a proposal for a
'protection_class=*' key to replace 'protect_class=*'. It replaces the
seven numeric codes from IUCN (plus a zoo of codes that OSM appears to
have cut out of whole cloth) with 'protection_object=*', whose values
are drawn from a group of word-oriented codes that, it is hoped, will
be more mnemonic. (The proposal to describe State Parks as protected
areas was reasonably well received except for the issue that it
depended on the numeric 'protect_class=*' to describe the protection.)

The proposal has now reached a state where I think it can be opened
for a formal RFC, and can be found at
https://wiki.openstreetmap.org/wiki/Proposal:_Named_protection_class_for_protected_areas
.

Of course, I'll monitor both this list and the talk page for the Wiki
page for comments, and try to address whatever comes up.
-- 
73 de ke9tv/2, Kevin

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