Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Joseph Eisenberg]

I've edited the page:

1) I reworded some of the helpful changes that Mateusz Konieczny just
made, for better English style.

2) I've removed the implication that de facto / approved are
"recommended" and that "deprecated" / "discardable" etc. are "not
recommended".

I also removed the suggestion that "de facto" tags are supported by
rendering / routing / editing software - while this is usually true,
it isn't what determines if a tag is given "de facto" status.

3) I removed "obsolete" status from the list with deprecated/discouraged.

However, I now think I figured out what this status is supposed to
mean: it's supposed to be used for tags that were deprecated, but now
no longer even appear in the database, so the wiki page is only for
historical information.

Do we really need a special status for this, or should is it ok if I
retag the 6 tags with this status to "deprecated"?

https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22obsolete%22

- Tag:abandoned=yes - recommended replacement abandoned:*=* - used 34,000 times
- Tag:amenity=Kneippbecken - approved replacement is
amenity=kneipp_water_cure - used 0 times
- Tag:man_made=power_hydro / Tag:man_made=power_nuclear /
Tag:man_made=power_wind - use  power=generator, generator:source=*
instead - used a couple of times only.
- Tag:denotation=cluster - for special trees. Recommend to use name=*
instead with natural=tree. Had been down to 0 uses at one point, but
now there are a few hundred?

So only amenity=Kneippbecken and man_made=power_* really fit the
"obsolete" status, though there are a number of tags currently with
"deprecated" that are also no longer found in the database.

Joseph

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

[Tagging] Specific tag for Satellite Dishes

[Enock Seth Nyamador]

Hello,

Sorry for cross posting.

I am looking for specific tags for Satellite Dish [1]. I haven't found
anything near so far. May be am missing something, else it doesn't exist
and might be useful to propose and come handy in some cases.

Ever mapped something like this or any idea will be great.

1. https://www.wikidata.org/wiki/Q253843

-- 
Best,
-Enock
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of State Parks in the US

[Joseph Eisenberg]

“how can a protected_AREA be anything but an area?”

Right. Please don’t add area=yes to these features.

This tag is only needed for features that can be either a linear feature OR
an area, for example barrier=hedge.

(Mapping large protected areas mapped as closed ways to relations of
type=boundary (or type=multipolygon) is also an effective way of specifying
that they are areas, though again I would not recommend retagging existing
features.)

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

Re: [Tagging] Tagging of State Parks in the US

[Kevin Kenny]

On Sun, Jul 28, 2019 at 5:56 PM Paul Allen  wrote:
> On Sun, 28 Jul 2019 at 22:35, Kevin Kenny  wrote:
>> Would it be appropriate to propose a mechanical edit to add area=yes
>> to closed ways that are tagged boundary={aboriginal_lands,
>> national_park, protected_area} and lack any other keys that would make
>> them polygons?
>
> Wearing my pedant hat, I'd say it's appropriate to propose just about 
> anything, however
> nonsensical.

Thanks for the levity!

> Taking off my pedant hat, I'd say that seems like a sensible thing to do.
> Putting on my cynic hat, I'd say you'll probably get too many objections for 
> it to happen:
> people will say you have to manually ensure area=yes is actually valid in 
> each situation;

Yeah. Although, how can a protected_AREA be anything but an area?  But
never mind that!

> others will say that mechanical edits should never be performed for any 
> reason;

Still, they get done from time to time. I've even seen bots come by
and tidy up things in my own work.

> a few will say we should not compensate for database/toolchain shortcomings by
> adding unnecessary tags.

Yeah. The ones who ignore the statement that you just made, " If it
breaks things, it won't be used."

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

Re: [Tagging] Tagging of State Parks in the US

[Kevin Kenny]

On Sun, Jul 28, 2019 at 5:47 PM Martin Koppenhoefer
 wrote:
> > On 28. Jul 2019, at 22:23, Kevin Kenny  wrote:
> >
> > But this doesn't really address the problem. We can't fix State Parks
> > by making them 'boundary=national_park admin_level=4' because they
> > don't function as 'national park' in the IUCN deffinition of the term.
>
>
> the proposal was boundary=protected_area
> admin_level=4
> you could also add a protection title.

Right. And the original proposal was to activate a protect_class=*
that was previously dormant, because nothing of 1a-6 fits the
situation. Many of these parks simply aren't created to conserve
nature, they're created to provide opportunities for a variety of
outdoor recreations.

admin_level isn't *wrong*, it just doesn't help. With or without
admin_level, there's no IUCN-defined protect_class that fits.

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

Re: [Tagging] Tagging of State Parks in the US

[Kevin Kenny]

On Sun, Jul 28, 2019 at 5:42 PM Paul Allen  wrote:
> On Sun, 28 Jul 2019 at 21:25, Kevin Kenny  wrote:
>
>> But this doesn't really address the problem. We can't fix State Parks
>> by making them 'boundary=national_park admin_level=4' because they
>> don't function as 'national park' in the IUCN deffinition of the term.
>> Instead, the typical State Park is a hybrid of nature_reserve and
>> recreation_ground and park and maybe a few other things. Requiring
>> that those land uses be mapped separately leaves no whole to which the
>> name and boundary can be assigned, but the whole doesn't really have
>> anything binding it together other than a protection status, a
>> coterminous set of boundaries and a name.
>
> Doesn't seem to fit national parks in the UK either.  See Pembrokeshire Coast 
> National
> Park: https://www.openstreetmap.org/relation/165598
>
> It is entirely within, and occupies a large part of, the county of 
> Pembrokeshire.  It is not
> administered by the UK Government, the Welsh Assembly or Pembrokeshire County
> Council but by the Pembrokeshire Coast National Park Authority.  See
> https://en.wikipedia.org/wiki/Pembrokeshire_Coast_National_Park
>
> The PCNPA owns less than 2% of the national park, the rest of it is privately 
> owned.  It contains
> 13 Special Areas of Conservation, 5 Special Protection Areas, 1 Marine 
> Conservation Zone,
> 7 National Nature Reserves, 60 Sites of Special Scientific Interest and 265 
> Scheduled
> Ancient Monuments, all of which come under one or another protection scheme 
> and are
> administered by different organizations.  See
> https://www.pembrokeshirecoast.wales/default.asp?PID=503  There are also 
> woodlands
> administered/protected by various different organizations.
>
> It also contains hamlets, villages, town and cities.  As well as everything 
> else you might expect
> to find in an area with a resident population of around 22,500 such as golf 
> courses, recreational
> parks, etc.
>
> Planning permission within the park is controlled by the PCNPA rather than 
> the County Council.
>
> It's all kind of complicated.

The Adirondack and Catskill Parks in New York are nearly a precise
parallel, including the complication that they are not chartered by
the Federal government. They're entirely within, and a creature of,
the State of New York.  (The Adirondack Park spans twelve counties -
at 24,000 km², it's the size of some European countries. The Catskill
Park is perhaps a sixth its size). They are read into the New York
State Constitution, so the unusual cooperative protection that they
enjoy is actually stronger than that of any of our National Parks
(which can, in theory, be wiped out by a simple act of Congress,
rather than a constitutional amendment).

The land ownership is roughly 50-50 public/private. Many of the
private landowners are logging companies, who are restricted to
sustainable harvest techniques and severely restricted against
repurposing the land. (Many also have public access easements in place
so that some areas not being actively logged are open to recreational
users.)

The local government system is complicated, but in the Adirondacks,
suffice it to say that the Adirondack Park Agency (a private-public
partnership between the local communities and the NY State Department
of Environmental Conservation) is the most powerful among the local
entities. Certainly, listings for property are more likely to say
whether they're inside or outside the park than what township or
county they're in, because that difference is more significant to the
landowner.

For the Adirondack Park alone, there are about forty Wilderness Areas
(comprising about 4800 km²), a somewhat greater number of Wild Forest
[a classification just below Wilderness] (about 5400 km²), about 5900
km² of Resource Management areas (in private hands, and mostly devoted
to logging), about 4000 km² devoted to Rural Use (mostly agriculture).
About 50 km² are even zoned as Industrial Use - mostly mining; the
park produces titanium, garnet and wollastonite.
About 1600 km² are devoted to human habitation, divided into about 60%
low-intensity (< 75 buildings/km²), 30% medium-intensity (75-200
buildings/km²), and 10% high-intensity (where there is no fixed limit
and most uses are permitted, although special hearings are needed for
subdivisions exceeding 100 lots, expansion into wetlands, airport
construction, and structures over 12 m above average terrain). It
contains also Primitive, HIstoric, Canoe, and Intensive Use areas.

There are about 130,000 permanent inhabitants, and the population
expands to about 320,000 seasonally, with nearly 10 million annual
visitors. There are two universities (Paul Smith's College and State
University of New York Environmental Science and Forestry), plus North
Country Community College. (There are a handful more just outside its
boundaries). SUNY-ESF maintains multiple research stations and
demonstration forests.

Some of the 'private' land 

Re: [Tagging] Tagging of State Parks in the US

[Martin Koppenhoefer]

sent from a phone

> On 28. Jul 2019, at 22:23, Kevin Kenny  wrote:
> 
> But this doesn't really address the problem. We can't fix State Parks
> by making them 'boundary=national_park admin_level=4' because they
> don't function as 'national park' in the IUCN deffinition of the term.


the proposal was boundary=protected_area
admin_level=4
you could also add a protection title.

Cheers Martin 

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

Re: [Tagging] Tagging of State Parks in the US

[Martin Koppenhoefer]

sent from a phone

On 28. Jul 2019, at 22:23, Kevin Kenny  wrote:

>> For specific kind of sites (e.g. protected under a specific international 
>> treaty) we could have specific tags to identify them if desired, e.g. 
>> protection_context=natura2000
>> or
>> protection_context=state_park
>> (not sure the latter would be adding information if there was already an 
>> admin_level=4 tag)
> 
> Already there - the 'protection_title' tag; plus, as you note,
> 'related_law'.It's pretty useless for rendering, though; there are too
> many administrative jurisdictions with too many detailed differences
> in their local laws.


this is not the same as protection title. It would make sense for cases like 
natura2000, i.e. protected sites that are also listed in the natura 2000 
network.
https://ec.europa.eu/environment/nature/natura2000/

related_law is ok for all sites designated by law, while it might also be seen 
to extend to international treaties, it would probably not be suitable to tie 
together networks of sites that are controlled by non-governmental actors.


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

Re: [Tagging] Tagging of State Parks in the US

[Paul Allen]

On Sun, 28 Jul 2019 at 21:25, Kevin Kenny  wrote:

But this doesn't really address the problem. We can't fix State Parks
> by making them 'boundary=national_park admin_level=4' because they
> don't function as 'national park' in the IUCN deffinition of the term.
> Instead, the typical State Park is a hybrid of nature_reserve and
> recreation_ground and park and maybe a few other things. Requiring
> that those land uses be mapped separately leaves no whole to which the
> name and boundary can be assigned, but the whole doesn't really have
> anything binding it together other than a protection status, a
> coterminous set of boundaries and a name.
>

Doesn't seem to fit national parks in the UK either.  See Pembrokeshire
Coast National
Park: https://www.openstreetmap.org/relation/165598

It is entirely within, and occupies a large part of, the county of
Pembrokeshire.  It is not
administered by the UK Government, the Welsh Assembly or Pembrokeshire
County
Council but by the Pembrokeshire Coast National Park Authority.  See
https://en.wikipedia.org/wiki/Pembrokeshire_Coast_National_Park

The PCNPA owns less than 2% of the national park, the rest of it is
privately owned.  It contains
13 Special Areas of Conservation, 5 Special Protection Areas, 1 Marine
Conservation Zone,
7 National Nature Reserves, 60 Sites of Special Scientific Interest and 265
Scheduled
Ancient Monuments, all of which come under one or another protection scheme
and are
administered by different organizations.  See
https://www.pembrokeshirecoast.wales/default.asp?PID=503  There are also
woodlands
administered/protected by various different organizations.

It also contains hamlets, villages, town and cities.  As well as everything
else you might expect
to find in an area with a resident population of around 22,500 such as golf
courses, recreational
parks, etc.

Planning permission within the park is controlled by the PCNPA rather than
the County Council.

It's all kind of complicated.

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

Re: [Tagging] Tagging of State Parks in the US

[Kevin Kenny]

On Sun, Jul 28, 2019 at 11:38 AM Paul Allen  wrote:
> On Sun, 28 Jul 2019 at 15:42, Kevin Kenny  wrote:
>> 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.
>
>
> Um, 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.

Sorry, I spoke sloppily. Having the word 'state' in the tag defining
the type of object is a recipe for confusion, just as IUCN's using
'national park' as a term of art and protection type rather than
specifically meaning a formal declaration that a given object is a
National Park has caused us tremendous amounts of confusion over the
years. That alone makes 'leisure=state_park' a non-starter by
comparison to some sort of 'boundary=*' or an entirely new key. There
are other facilities that are functionally identical that aren't
'state parks', and using that tag to describe them will cause
arguments for years.

>> 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.

Our National Parks often have substantial inholdings as well. We're
not as different as you imagine. Also, as I describe in
https://www.openstreetmap.org/user/ke9tv/diary/390233, I've used
'boundary=national_park' on a couple of carefully selected objects
that are not National Parks, and in fact, are not even Federal.
Richard Fairhurst tells me that he's comfortable with my choice of
tags for those, and I understand he's rather a mapping luminary in the
UK. He's also *been* to the parks in question, and so is familiar with
what they look like on the ground. They, too, encompass villages,
farms, working forest, and mines, as well as recreational areas and
protected wilderness. Nevertheless, they're overseen by what's been
called "the world's strictest zoning board", and development is
rigorously constrained.

> [...] I'd say that using a valid tag
> in a valid way isn't wrong, it's lying for the renderer that is wrong.  [...]

THANK YOU!  'Tagging for the renderer' is doing things like one that I
cleaned up a few years back, when a mapper was drawing depth contours
in a nearby lake as 'highway=cycleway name="20 ft"'. It might produce
a nice blue dotted line on the map, but it's got nothing to do with
the feature! (Bathymetry is something that OSM doesn't contemplate
mapping, so these simply got deleted after discussion with the mapper
in question). It isn't 'tagging for the renderer' when I look at a
state park and try to decide whether 'landuse=recreation_ground' or
'leisure=nature_reserve' or 'leisure=park' or 'boundary=national_park'
or one of zoo of other things will be a better fit under current
tagging practice. It's tagging for the future when I also tag
'boundary=protected_area protect_class=21' - even if we decide that
protect_classes other than IUCN's were a bad idea, that tagging says
that a mapper thought about the situation and decided on that class -
and provides a clear signpost for a task manager or mechanical edit to
convert the tags if we decide on something else.

>> 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.

site_ownership=* and operator=* seem to do that pretty well, I think.
Some of these features don't even have an admin_level. We have some
pretty big public-access nature reserves managed by NGO's.

>>   * 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.

That's not a good analogue to State Park, and *is* a good analogue to
existing uses of 'boundary=national_park' on both sides 

Re: [Tagging] Tagging of State Parks in the US

[Kevin Kenny]

On Sun, Jul 28, 2019 at 10:36 AM Martin Koppenhoefer
 wrote:
> we do have an established numbered scheme for admin_levels, it could be 
> reused to tag the administrative level that instituted the protected area, 
> for a state park it would have the value 4, the key could remain 
> “admin_level” also in the context of boundary=protected_area
>
> It seems straightforward.

Far from straightforward! It's perfectly straightforward to describe
the admin_level that runs a park. But admin_level is in no way the
source of the tagging puzzle.

The protected_area tagging, if we are to follow IUCN guidelines, does
not depend on the level of government. Under IUCN definitions, a
'national park' does NOT have to be administered by a sovereign
nation. It has to ''quack like a duck" - be a "large natural or
near-natural areas protecting large-scale ecological processes with
characteristic species and ecosystems, which also have environmentally
and culturally compatible spiritual, scientific, educational,
recreational and visitor opportunities".

In fact, I'd like to avoid even recommending 'admin_level' in favour
of 'operator' and 'site_ownership', both of which are already
frequently used. It avoids confusion in a weird case like the New York
City watershed recreation units. The weirdness comes from the fact
that the units lie *outside* New York City, and New York City isn't
their governing entity. It simply owns them as a private party would -
having purchased the land from a willing seller in order to keep it
from development. It then allows public access, just as some generous
private parties (notably, the land trusts) do. What level of
government administers them? None of the answers make sense, but
operator="New York City Department of Environmental Protection, Bureau
of Water Supply" makes perfect sense.  There really isn't much of a
case for admin_level here. (I don't *mind* it in cases where it's more
meaningful, but don't go out of my way to tag it, because it doesn't
really inform anything.)

> The kind of protection could be readable words, like nature, or birds, or 
> culture, or water, air etc. (we’ll see what is needed when we do it). Don’t 
> know for the key, it seems reasonable not to reuse protect_class. Maybe
> “protected:for”
> or the no underscore/colon variant:
> “protection” and the goods/qualities that are protected as value.

Already there - the 'protection_object' tag. (I use it pretty
consistently for class 3/4/5/6 areas; 1, 1a and 2, it becomes
meaningless, because the protection object tends to be 'everything
under the Sun'). It'd be a challenge for rendering because there are
so many things that might be protected.

> For specific kind of sites (e.g. protected under a specific international 
> treaty) we could have specific tags to identify them if desired, e.g. 
> protection_context=natura2000
> or
> protection_context=state_park
> (not sure the latter would be adding information if there was already an 
> admin_level=4 tag)

Already there - the 'protection_title' tag; plus, as you note,
'related_law'.It's pretty useless for rendering, though; there are too
many administrative jurisdictions with too many detailed differences
in their local laws.

But this doesn't really address the problem. We can't fix State Parks
by making them 'boundary=national_park admin_level=4' because they
don't function as 'national park' in the IUCN deffinition of the term.
Instead, the typical State Park is a hybrid of nature_reserve and
recreation_ground and park and maybe a few other things. Requiring
that those land uses be mapped separately leaves no whole to which the
name and boundary can be assigned, but the whole doesn't really have
anything binding it together other than a protection status, a
coterminous set of boundaries and a name.

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Mateusz Konieczny]

28 Jul 2019, 11:12 by o...@imagico.de:

> On Saturday 27 July 2019, Joseph Eisenberg wrote:
>
>> Please take a minute to review the new page
>> https://wiki.openstreetmap.org/wiki/Approval_status 
>> 
>>
Thanks for creating it and submitting it for a review!

> A bit of a general remark here - the OSM wiki has for quite some time 
> been torn between being an attempt to document the established mapping 
> practice (i.e. what tags actually mean based on how they are used) and 
> being a way to tell mappers what tags are supposed to mean in the 
> opinion of those editing the wiki.
>
I edited Deprecated features page to be more explicit that
wiki editors are documenting tagging situations, rather than ordering mappers
and developers how this should be used

See
https://wiki.openstreetmap.org/w/index.php?title=Deprecated_features=historysubmit=revision=1882964=1820343
 

for my changes, feedback is welcomed.

> The way you present this status concept is in support of the latter - in 
> particular your use of the term "recommended" on status values that do 
> not represent a formal proposal status (that 
> is 'draft', 'proposed', 'voting', 'approved' and 'rejected') ultimately 
> means recommended by those who have dominance over editing the wiki.
>
I made some small changes, see
https://wiki.openstreetmap.org/w/index.php?title=Approval_status=revision=1882980=1882393
 


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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Mateusz Konieczny]

28 Jul 2019, 18:33 by o...@imagico.de:

>
> IMO if those criteria are significant (which i don't doubt as far as 
> they can be objectively determined) it is much more useful to document 
> how far a tag meets these criteria individually than to determine an 
> aggregate score of some sort from them and a categorization based on 
> that.
>
>

The longer that I look at it the more I suspect that clasiffying "de facto" vs 
"in use" is 
not very useful.

-- signed, person who made many edits on Wiki changing "de facto" to "in use" 
or reverse

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Christoph Hormann]

There are many tags with status 'de facto' indicated that do not meet at 
least some of your criteria:

landuse=meadow
landuse=forest
natural=wood
place=square
waterway=drain

and there are tags with status 'in use' indicated that at least meet 
some of the criteria:

highway=turning_circle
information=guidepost
landuse=grass
man_made=cutline
place=archipelago
water=lake
waterway=riverbank

IMO if those criteria are significant (which i don't doubt as far as 
they can be objectively determined) it is much more useful to document 
how far a tag meets these criteria individually than to determine an 
aggregate score of some sort from them and a categorization based on 
that.

-- 
Christoph Hormann
http://www.imagico.de/

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

[Tagging] Feature proposal - Approved - Line attachments

[François Lacombe]

Hi all,

Voting period on line attachments proposal is now over.
23 pros votes make the new key line_attachment approved, thanks to voters
for their support
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_attachments

The proposal took approx 1 year to be mature enough for the vote and
reworked several times thanks to TOGA's comments

The wiki is currently edited with new values for the proposed key.
tower:type=anchor and tower:type=suspension should now be carefully
replaced with appropriate line_attachment values.
Feel free to complete example sections for each page with situations you
see

All the best

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

Re: [Tagging] Tagging of State Parks in the US

[Martin Koppenhoefer]

sent from a phone

> On 28. Jul 2019, at 17:34, Joseph Eisenberg  
> wrote:
> 
> While admin_level is numeric, they numbers are already widely known,
> so it would be fine to reuse the tag admin_level=4 to specify the
> administrative level of a certain protected area, I think, especially
> if the operator=* is not the same.


yes, they are widely known and there are reasons why a number might be better 
than words in this specific case: you can directly see the hierarchy even if 
you don’t understand the words that are used for naming it (indeed countries 
are using different systems and names for their subdivisions). It may also seem 
to imply some kind of correspondence between the same level in different 
countries, but this is very loose because the systems can be very different.

Great we’re moving away from numbered protect classes.


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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Joseph Eisenberg]

I don't think it would be easy to automate.

My impression is that the "de facto" status tags and keys area usually:

1) In use for a long time.

Most are been around since 2008 or sooner, but at least for several
years if newer. This requires checking http://taghistory.raifer.tech
or old database extracts, or having personal knowledge of the
situation.

2) Are used for a large percentage of all the real world features of
that type, or have high and growing usage.

This requires knowing that 5 oceans, 7 continents, or 220 countries is
100 percent, but 500 tree stumps is not very much. I don't think
computers are so good at this.

3) Are not debatable or in conflict with a synonymous tag

This requires knowing what other tags mean the same thing or nearly
the same thing, and checking the Talk page and old forum or Tagging
mailing list archives and old draft proposals to see if any serious
problems came up.

4) Have a clear definition and reasonably complete wiki documentation

This is pretty easy for a human to check, but not so easy for a computer.

(And the prerequisite is that there wasn't an approved proposal in the
past, which also requires searching the archives; otherwise it should
be "approve" )

I think these 4 criteria are fairly objective, but not something that
can be determined by a simple algorithm.

If they are not met, the tag is probably "in use" if it's being
currently added by mappers this year.

Tags that meet all 4 criteria are probably as good as the average "Approved" tag

- Joseph

On 7/28/19, Christoph Hormann  wrote:
> On Sunday 28 July 2019, Joseph Eisenberg wrote:
>>
>> Christoph, do you have any ideas about how we could be more inclusive
>> and make it easier for mappers from other countries to create and
>> document new tags?
>
> I think emphasizing and reaffirming the fact that the wiki is to
> document the de facto use and meaning of tags and openly documenting
> and explaining contradictions, ambiguities and regional differences in
> tagging rather than hiding them to present a subjectively desired
> reality of tagging would be a good approach.
>
> If the wiki documents the de facto use and meaning of tags that would
> automatically give different language versions of the documentation
> equal standing because all of them aim to document the same thing.  If
> however the wiki aims to document the supposed meaning of tags there
> will inevitably be a struggle for opinion leadership on what this
> supposed meaning is to be and this struggle will inevitably be
> dominated by the English language.
>
> What i specifically think is not a good idea is intermixing the formal
> status of a proposal in the proposal process
> ('draft', 'proposed', 'voting', 'approved' and 'rejected') with either
> objective and verifiable classifications of the actual use of tags and
> subjective recommendations if a certain tag should or should not be
> used.
>
>> I hoped that by better defining the "de facto" status and defining a
>> clear way that a tag can be promoted to this value (which currently
>> is honored with a green highlighting, just like "approved"), there
>> could be an objective and fair way for "in use" tags to be added to
>> Map Features without going through the Proposal process.
>
> I don't think there is a reasonable verifiable way to define a
> sub-classification among tags that are widely accepted to be used with
> a certain meaning but that have never successfully gone through a
> proposal process.  If there was a way to do this it would probably be
> possible to automatically determine this and show such status in
> taginfo (although if that involves the historic development that might
> be technically challenging).
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] Tagging of State Parks in the US

[Paul Allen]

On Sun, 28 Jul 2019 at 15:42, Kevin Kenny  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.


Um, 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of State Parks in the US

[Joseph Eisenberg]

While admin_level is numeric, they numbers are already widely known,
so it would be fine to reuse the tag admin_level=4 to specify the
administrative level of a certain protected area, I think, especially
if the operator=* is not the same.

> 'strict_nature_reserve', 'wilderness_area',
'national_park' (already used), 'natural_monument', 'habitat',
'protected_landscape', 'sustainable_resource_use_area

Great idea. I can actually remember those. Perhaps we can create
specific wiki pages for each of the protect_class=1 to 6 and add those
definitions, to help out taginfo and editors like iD and JOSM. I would
also probably vote for a proposal that added new tags like
*=wilderness_area, *=natural_monument, and deprecated protect_class.

There will need to be synonyms for 11 to 19 as well, since these are
used in some countries according to the table, as well as for at least
a few of the Social/Cultural ones.

Are you feeling up to writing a big proposal, Kevin? It may be a lot a
work and probably requires consulting with other communities (like
German at least), but I think you have the persistence to get it done.

Joseph

On 7/29/19, Paul Allen  wrote:
> On Sun, 28 Jul 2019 at 15:36, Martin Koppenhoefer 
> wrote:
>
> we do have an established numbered scheme for admin_levels, it could be
>> reused to tag the administrative level that instituted the protected
>> area,
>> for a state park it would have the value 4, the key could remain
>> “admin_level” also in the context of boundary=protected_area
>>
>
> I'm not entirely happy with admin_level.  It's numbers, so you have to read
> the wiki to figure out
> what admin_level=4 is.  I view it as a historical accident that we should
> avoid repeating, not a
> template for good taq design.
>
> The kind of protection could be readable words, like nature, or birds, or
>> culture, or water, air etc.
>>
>
> A lot better than numbers.  Still has problems, such as some objects will
> need to have a list
> of values because it serves multiple purposes, but better than
> randomly-assigned numbers.
>
> --
> Paul
>

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

Re: [Tagging] Tagging of State Parks in the US

[Paul Allen]

On Sun, 28 Jul 2019 at 15:36, Martin Koppenhoefer 
wrote:

we do have an established numbered scheme for admin_levels, it could be
> reused to tag the administrative level that instituted the protected area,
> for a state park it would have the value 4, the key could remain
> “admin_level” also in the context of boundary=protected_area
>

I'm not entirely happy with admin_level.  It's numbers, so you have to read
the wiki to figure out
what admin_level=4 is.  I view it as a historical accident that we should
avoid repeating, not a
template for good taq design.

The kind of protection could be readable words, like nature, or birds, or
> culture, or water, air etc.
>

A lot better than numbers.  Still has problems, such as some objects will
need to have a list
of values because it serves multiple purposes, but better than
randomly-assigned numbers.

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Martin Koppenhoefer]

sent from a phone

> On 28. Jul 2019, at 15:37, Christoph Hormann  wrote:
> 
> I don't think there is a reasonable verifiable way to define a 
> sub-classification among tags that are widely accepted to be used with 
> a certain meaning but that have never successfully gone through a 
> proposal process.


I also don’t think it would be useful or needed. What should be possible is 
distinguishing these widely accepted and established tags you mention from 
those tags that are not widely known and used, but are documented nonetheless 
and there is some few usage.


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

Re: [Tagging] Tagging of State Parks in the US

[Kevin Kenny]

On Sun, Jul 28, 2019 at 8:04 AM Paul Allen  wrote:
> I have no objections to protect_class as supplemental information that data 
> consumers can make
> use of as they wish (including ignoring it).  I have an intense dislike of 
> numbers being used for
> anything other than numeric values because they are not amenable to human 
> inspection.  Sure,
> editors can unobfuscate things by using an internal lookup table, but that 
> isn't a complete solution.
> Compare an overpass-turbo query for leisure=state_park and for 
> protect_class=21.

I dislike the numeric classification as well.

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. Bethpage State Park wouldn't be turned into condos
just because some future administration decides that the state's money
ought to subsidize something other than golf - it would be repurposed
to some other recreational use. (The legality of releasing it from
protection would be a complex political question; repurposing it from
one recreation to another could be an administrative decision by the
executive branch.)

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. We already struggle with
that issue every time that the national_park tag comes up, because
'national park' to IUCN describes a purpose and level of protection,
not a particular ownership. In fact, IUCN's guidelines have a
cross-cutting taxonomy of management that divides it into four
categories: government (including national, sub-national and delegated
entities  - the last refers to formal delegation to an NGO); shared
(collaborative; joint; transboundary); private (individual; nonprofit
- NGO, university, cooperative; for-profit); indigenous (declared and
run by the local indigenous community). Any of these can apply to any
of the types; hence, in areas that I try to curate, there are some
relatively surprising combinations. The Adirondack Park is a
non-Federal 'national_park' with shared (collaborative) management
between the state of New York and private landowners; the New York
City watershed is a set of sustainable-resource-use protected areas
with private management (It's outside the city's boundaries. New York
City is not its government, merely its landowner functioning in the
capacity of a private entity); the Huyck Preserve is a habitat area
with autonomous NGO management; and so on. It's really important NOT
to think of the problem as being 'the wrong level of government.' Even
my for-profit employer is in the game. There are a couple of
recreation grounds near my work site that are owned by the company but
used by the town under a permanent easement. They exist in part
because there is a required setback of 500 m (I may be wrong about the
figure) between certain hazardous activities at my workplace and
permanent human habitation, but I'm sure that the company is also glad
to get the tax writeoff and have its name on the sign as the donor.

The 'boundary=recreational_area' idea would work for me if people were
actually to get behind it.  We would, of course, have to address 3785
somehow - and deal with the fact that means a database reload. Just as
'protect_class=24' is now dead (replaced with aboriginal_lands), we
could migrate the other protections over to a named scheme.

In fact, that would work with the IUCN codes as well - we don't have
to use them unchanged, we can name them!  (Of course, we could
preserve a correspondence between IUCN's taxonomy and ours, and
continue to accept the IUCN codes as synonyms.) In fact, IUCN gives
names to the categories in
https://www.iucn.org/theme/protected-areas/about/protected-area-categories
- although we OSM'ers would probably go with something a trifle less
verbose, such as 'strict_nature_reserve', 'wilderness_area',
'national_park' (already used), 'natural_monument', 'habitat',
'protected_landscape', 'sustainable_resource_use_area'.

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.  The only thing that kept the idea alive for me was
that 'area=yes' is available as a workaround, and that most areas
tagged with 'boundary=protected_area' also have other tagging that
does force a polygon to be created, although there appear to be
thousands that do not.

So, I'd like to 

Re: [Tagging] Tagging of State Parks in the US

[Martin Koppenhoefer]

sent from a phone

> On 28. Jul 2019, at 14:03, Paul Allen  wrote:
> 
> I have an intense dislike of numbers being used for
> anything other than numeric values because they are not amenable to human 
> inspection.  Sure,
> editors can unobfuscate things by using an internal lookup table, but that 
> isn't a complete solution.
> Compare an overpass-turbo query for leisure=state_park and for 
> protect_class=21.  Use the query
> tool of standard carto and ask yourself how easy it would be to guess what is 
> meant by
> leisure=state_park versus protect_class=21. 


we do have an established numbered scheme for admin_levels, it could be reused 
to tag the administrative level that instituted the protected area, for a state 
park it would have the value 4, the key could remain “admin_level” also in the 
context of boundary=protected_area

It seems straightforward.

The kind of protection could be readable words, like nature, or birds, or 
culture, or water, air etc. (we’ll see what is needed when we do it). Don’t 
know for the key, it seems reasonable not to reuse protect_class. Maybe 
“protected:for”
or the no underscore/colon variant:
“protection” and the goods/qualities that are protected as value.

For specific kind of sites (e.g. protected under a specific international 
treaty) we could have specific tags to identify them if desired, e.g. 
protection_context=natura2000
or
protection_context=state_park
(not sure the latter would be adding information if there was already an 
admin_level=4 tag)

or from current (modest) usage, it could be “related_law” 
https://taginfo.openstreetmap.org/search?q=natura2000#values

Cheers Martin 


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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Christoph Hormann]

On Sunday 28 July 2019, Joseph Eisenberg wrote:
>
> Christoph, do you have any ideas about how we could be more inclusive
> and make it easier for mappers from other countries to create and
> document new tags?

I think emphasizing and reaffirming the fact that the wiki is to 
document the de facto use and meaning of tags and openly documenting 
and explaining contradictions, ambiguities and regional differences in 
tagging rather than hiding them to present a subjectively desired 
reality of tagging would be a good approach.

If the wiki documents the de facto use and meaning of tags that would 
automatically give different language versions of the documentation 
equal standing because all of them aim to document the same thing.  If 
however the wiki aims to document the supposed meaning of tags there 
will inevitably be a struggle for opinion leadership on what this 
supposed meaning is to be and this struggle will inevitably be 
dominated by the English language.

What i specifically think is not a good idea is intermixing the formal 
status of a proposal in the proposal process 
('draft', 'proposed', 'voting', 'approved' and 'rejected') with either 
objective and verifiable classifications of the actual use of tags and 
subjective recommendations if a certain tag should or should not be 
used.

> I hoped that by better defining the "de facto" status and defining a
> clear way that a tag can be promoted to this value (which currently
> is honored with a green highlighting, just like "approved"), there
> could be an objective and fair way for "in use" tags to be added to
> Map Features without going through the Proposal process.

I don't think there is a reasonable verifiable way to define a 
sub-classification among tags that are widely accepted to be used with 
a certain meaning but that have never successfully gone through a 
proposal process.  If there was a way to do this it would probably be 
possible to automatically determine this and show such status in 
taginfo (although if that involves the historic development that might 
be technically challenging).

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Joseph Eisenberg]

I think Christoph brings up a very good point.

If I understand correctly, he wasn't accusing the new page of saying
"this is the right way to use statuses", since it just describes and
explains how the current "status" feature is currently used.

But rather, he was saying that by just describing the current way that
the wiki is used, it perpetuates the current system that is
systemically tilted toward English-speaking, privileged Westerners
such as ourselves.

While in theory anyone can edit the wiki or join the Tagging group,
there are in practice only a few hundred people who do either, out of
the many thousands of mappers and many millions of users, and those of
use who contribute here and on the wiki are mainly Europeans (plus
their old colonialists from America, Australia etc) who read and write
English fluently.

I live in Papua, Indonesia, but I'm well aware that my background and
preconceptions and values are very different those of most Papuans and
other Indonesians.

Christoph, do you have any ideas about how we could be more inclusive
and make it easier for mappers from other countries to create and
document new tags?

I hoped that by better defining the "de facto" status and defining a
clear way that a tag can be promoted to this value (which currently is
honored with a green highlighting, just like "approved"), there could
be an objective and fair way for "in use" tags to be added to Map
Features without going through the Proposal process.

This would allow, say, and Indonesian mapper to start using
"amenity=motorcycle_taxi" for Ojek stands
(https://en.wikipedia.org/wiki/Motorcycle_taxi) or even "amenity=ojek"
- and if the gained enough popularity and met the criteria it could be
given status=defacto and added to Map Features without having a
proposal.

I'd say this should happen even when the tag isn't really in British
English, if it's been organically accepted by mappers - for example,
we use amenity=bureau_de_change instead of amenity=currency_exchange
or =money_changer

But I also see a benefit to not allowing just any tag to be added to
Map Features without discussion, especially if they are not commonly
used, don't have a clear definition, aren't verifiable by ordinary
mappers, etc.

Joseph

On 7/28/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 28. Jul 2019, at 11:12, Christoph Hormann  wrote:
>>
>> ultimately
>> means recommended by those who have dominance over editing the wiki
>
>
> who are they? Everybody can modify the wiki (and indeed from my experience
> the wiki is more the sum of many individual, punctual and sometimes even
> disconnected edits and additions, than it is the result of an orchestrated
> effort by a small group of self-elected dominators). When there are disputes
> about edits they are usually brought to discussion on the mailing lists and
> “forums”, and if you decide not to participate in any of this, you will have
> to live with what the others do (not speaking about you, Christoph,
> personally). Joseph didn’t introduce the tag status concept, he is only
> trying to improve the documentation and find the common understanding of
> what these “statuses” mean and how they are assigned, which should make it
> easier for newcomers to engage in the discussions about topics they care
> for.
>
>> In contrast to the verbalized
>> documentation of tags - which can exist in any language or set of
>> languages independent of each others the idea of a tag status is that
>> of a single status defined by authority over the global OSM community.
>
>
>
> I believe it is desirable to have a single status and meaning for a tag. The
> project scope is global and there is no need to re-use the same tag for a
> different meaning or insist on deprecation of a tag that is significantly
> used in some other areas and works for those who use it. Just use a
> different or additional tag for your specific meaning. Ultimately it isn’t a
> huge issue if occasionally different tags are used for the same or very
> similar feature class or property, but it is an issue if the same tag is
> defined differently in different languages. This does not exclude that the
> same tag may have a specific meaning just for an explicitly defined area
> (e.g. uk crossing shortcuts), or that it could not shift with the time.
>
> Cheers Martin
>
>
> ___
> 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] New page "Approval status" for "de facto", "in use", "approved" etc

[Joseph Eisenberg]

Correction: obsolete is only used 6 times with tags and 0 keys at the
moment, but "discardable" is also used with 7 keys in addition to 1
tag, so that's 8 times.

The "discardable" status is clearly different from "deprecated" as you
mentioned.

>> Perhaps there should be a wiki page created that described the process
>> for deprecating a tag and when to change the status?
>
> I guess there may be different opinions how and when a tag becomes
> deprecated, a wiki page would help to gather information and consolidate on
> an agreed meaning/process.

It would be good to get some ideas about how to describe the correct
way to deprecate a feature.

I remember it was hard to figure out how to add a new item to the
Deprecated Features page (camp_site=camp_pitch in my case), and there
wasn't in mention in the Proposal Process page.

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

Re: [Tagging] Tagging of State Parks in the US

[Paul Allen]

On Sun, 28 Jul 2019 at 02:36, Paul Johnson  wrote:

> I'm on board with a state park specific tag.  I find protect class to be a
> clunky answer and not entirely humanly intuitive compared to something like
> leisure=state_park
>

+1

I have no objections to protect_class as supplemental information that data
consumers can make
use of as they wish (including ignoring it).  I have an intense dislike of
numbers being used for
anything other than numeric values because they are not amenable to human
inspection.  Sure,
editors can unobfuscate things by using an internal lookup table, but that
isn't a complete solution.
Compare an overpass-turbo query for leisure=state_park and for
protect_class=21.  Use the query
tool of standard carto and ask yourself how easy it would be to guess what
is meant by
leisure=state_park versus protect_class=21.  Look at the raw tags in the
editor (something I
frequently do, for one reason or another) and see if leisure=state_park
makes more or less
sense than protect_class=21.

But if we insist that protect_class=21 is a sensible solution, then so is
replacing all existing
top=level tags with things like object=Q1234 and object=Q9876.  Well, that
doesn't cope with
values, so we'd have to replace building=house with object=Q1234 +
Q1234=Q9876.
Obviously (I hope) this is not a sensible solution, but it is merely a
logical extension of
the thinking that gives us protect_class=21 as a top-level tag.

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Martin Koppenhoefer]

sent from a phone

> On 28. Jul 2019, at 11:12, Christoph Hormann  wrote:
> 
> ultimately 
> means recommended by those who have dominance over editing the wiki


who are they? Everybody can modify the wiki (and indeed from my experience the 
wiki is more the sum of many individual, punctual and sometimes even 
disconnected edits and additions, than it is the result of an orchestrated 
effort by a small group of self-elected dominators). When there are disputes 
about edits they are usually brought to discussion on the mailing lists and 
“forums”, and if you decide not to participate in any of this, you will have to 
live with what the others do (not speaking about you, Christoph, personally). 
Joseph didn’t introduce the tag status concept, he is only trying to improve 
the documentation and find the common understanding of what these “statuses” 
mean and how they are assigned, which should make it easier for newcomers to 
engage in the discussions about topics they care for.

> In contrast to the verbalized 
> documentation of tags - which can exist in any language or set of 
> languages independent of each others the idea of a tag status is that 
> of a single status defined by authority over the global OSM community.



I believe it is desirable to have a single status and meaning for a tag. The 
project scope is global and there is no need to re-use the same tag for a 
different meaning or insist on deprecation of a tag that is significantly used 
in some other areas and works for those who use it. Just use a different or 
additional tag for your specific meaning. Ultimately it isn’t a huge issue if 
occasionally different tags are used for the same or very similar feature class 
or property, but it is an issue if the same tag is defined differently in 
different languages. This does not exclude that the same tag may have a 
specific meaning just for an explicitly defined area (e.g. uk crossing 
shortcuts), or that it could not shift with the time.

Cheers Martin 


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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Eugene Alvin Villar]

On Sat, Jul 27, 2019 at 10:20 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> Please take a minute to review the new page
> https://wiki.openstreetmap.org/wiki/Approval_status
>

Overall, this looks pretty good! I am in favor of documenting the status of
tags and this wiki page is a good start to explain what those statuses
mean. Mappers may quibble about the exact or specific meanings of
particular values, but at least this wiki page provides a central place to
collect such discussions (via the talk page) instead of or in addition to
this mailing list.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Christoph Hormann]

On Saturday 27 July 2019, Joseph Eisenberg wrote:
> Please take a minute to review the new page
> https://wiki.openstreetmap.org/wiki/Approval_status
>
> [...]

A bit of a general remark here - the OSM wiki has for quite some time 
been torn between being an attempt to document the established mapping 
practice (i.e. what tags actually mean based on how they are used) and 
being a way to tell mappers what tags are supposed to mean in the 
opinion of those editing the wiki.

The way you present this status concept is in support of the latter - in 
particular your use of the term "recommended" on status values that do 
not represent a formal proposal status (that 
is 'draft', 'proposed', 'voting', 'approved' and 'rejected') ultimately 
means recommended by those who have dominance over editing the wiki.

You should keep in mind that this whole concept of meta-classification 
of tags into a set of classes - as attractive as it might be to allow a 
simplistic understanding of tagging in OSM and management of the 
complexity of tagging by a small group of people on the wiki - is going 
to inevitably fail because it tries to trivialize the complexity of the 
geography (which we try to document in tagging) and the social 
dimension of very different people looking at this geography from 
different sides.  The only way to properly document the status of a tag 
is IMO through a verbalized description - which is the essence of what 
tag documentation on the wiki traditionally was centered around.

Also keep in mind that most of concept this idea of tag 'status' is 
based on massively discriminating against languages other than English.  
For the proposal process this is obvious but this also applies to many 
of the other ideas of status.  In contrast to the verbalized 
documentation of tags - which can exist in any language or set of 
languages independent of each others the idea of a tag status is that 
of a single status defined by authority over the global OSM community.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Martin Koppenhoefer]

sent from a phone

> On 28. Jul 2019, at 10:03, Joseph Eisenberg  
> wrote:
> 
> But "obsolete" is only used 6 times, and seems to mean the same thing
> as "deprecated". Perhaps we can just edit these 6 features and remove
> the status to simplify things?
> https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22obsolete%22
> 



+1, the differences seem minor, probably not worth the fragmentation



> Also, I've also only been able to find one wiki page with
> status=discardable - Tag:odbl=clean - so I think we can just change
> this tag status to "deprecated" and remove the special status for this
> one tag? 
> https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22discardable%22


here I see more profound differences in meaning: a discardable tag is 
completely useless (currently) and you should remove it when you are touching 
such an object. Deprecated tags on the other hand are just an alternative way 
to say something (they might have problems, eg ambiguity as in landuse=farm), 
but the tag has some meaning (should not be removed from an object without 
verifying there are other tags that convey the meaning).



> 
> Re: when to mark a tag as deprecated:
> 
> Ideally there should be a proposal approved which clearly states that
> a certain tag will be deprecated and another tag approved, but there
> appear to be a number of tags that are marked as "deprecated" due to
> some discussion but not a full vote.
> 
> In other cases it appears that deprecation was intended (eg
> amenity=embassy), but the tag is still commonly used and supported
> since the proposal was just approved.
> 
> Perhaps there should be a wiki page created that described the process
> for deprecating a tag and when to change the status?


I guess there may be different opinions how and when a tag becomes deprecated, 
a wiki page would help to gather information and consolidate on an agreed 
meaning/process.

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

Re: [Tagging] Tagging of State Parks in the US

[Martin Koppenhoefer]

sent from a phone

> On 28. Jul 2019, at 07:51, Joseph Eisenberg  
> wrote:
> 
> I didn’t realize that all of the protect_class>6 values were invented for 
> osm. In that case, I see no reason to use any values for protect_class above 
> 7. 
> 
> None of the higher values is used very frequently, and it’s impossible for me 
> to remember which each one means, especially the values from 21 to 27.
> 
> I think it would be easier for everyone if we created new tags for specific 
> things like protected recreation areas, protected historic or cultural sites 
> and protected sacred sites, as has been done with boundary=aboriginal_lands


+1, number codes are not a good solution if human mappers should assign them, 
even less if they aren’t about a gradation (like tracktype) and if there are a 
lot of them (harder to remember, like protected area types).

The fact the scheme wasn’t completed in all those years since 2011 doesn’t make 
it more appealing.
While being presented on a long page with lots of information (hence appearing 
to be exhaustive), if you actually want to classify an area it frequently 
happens that the definitions are not sufficient for describing the kind of 
protection and distinguishing it from other similar protected areas

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Joseph Eisenberg]

Good point about "deprecated" and "obsolete".

The status "deprecated" is much more common; it's been used 115 times
and has a well-used list:

But "obsolete" is only used 6 times, and seems to mean the same thing
as "deprecated". Perhaps we can just edit these 6 features and remove
the status to simplify things?
https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22obsolete%22

Also, I've also only been able to find one wiki page with
status=discardable - Tag:odbl=clean - so I think we can just change
this tag status to "deprecated" and remove the special status for this
one tag? 
https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22discardable%22

Re: when to mark a tag as deprecated:

Ideally there should be a proposal approved which clearly states that
a certain tag will be deprecated and another tag approved, but there
appear to be a number of tags that are marked as "deprecated" due to
some discussion but not a full vote.

In other cases it appears that deprecation was intended (eg
amenity=embassy), but the tag is still commonly used and supported
since the proposal was just approved.

Perhaps there should be a wiki page created that described the process
for deprecating a tag and when to change the status?

Joseph

On 7/28/19, Martin Koppenhoefer  wrote:
>> On 27. Jul 2019, at 16:19, Joseph Eisenberg 
>> wrote:
>> Please take a minute to review the new page
>> https://wiki.openstreetmap.org/wiki/Approval_status
>
> Allow me one remark for deprecated and obsolete. Currently it reads:
> “
> deprecated: deprecated tags that will not be used anymore”
>
> this could be less absolute and maybe include reference to the process,
> something like “tags which are discouraged by an approved proposal”
>
> Those tags that are discouraged because of a more established tagging
> alternative but not through voting would be “obsolete”, right? On the other
> hand for obsolete tags there is the requirement of “unapproved”, which
> probably leads to all obsolete approved tags going to deprecated status.
> Then to cover the formerly approved tags which haven’t been voted on their
> deprecation (other than by their “feet”), but are now considered deprecated,
> we should not require a vote on deprecation.
>
> “deprecated tags whose usage is commonly or by voting discouraged”
> or
> “deprecated tags whose usage is discouraged because of the tag usage history
> or as the result of voting“
> or even shorter, given that there are more verbose explanations below:
> “deprecated tags whose usage is discouraged”
>
>
>
> Cheers Martin
>
>
>

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