User talk:Viper444/Public Protected and Restricted Lands

Looking forward to feedback and ideas on this. Please chime in if you have an idea! --Viper444 (talk) 09:14, 8 September 2020 (UTC)

Interesting. However, this does build upon using tag park:type=*, which I indavertently used around 2009-10 in an old-fashioned import (OSM didn't have Import Guidelines back then). That tag became rather wildly out-of-control, and for about the last year as I wiki-documented it, seems to have gained some consensus that it be replaced by more modern tagging and eventually deprecate. There are both a table in that wiki with proposed old-style -> new-style tagging conventions, as well as its Discussion page suggesting a couple of smaller-scale demonstration projects that would begin to systematically deprecate this tag on a state-by-state and eventually nation-by-nation basis.

And, because you linked one of them to here, there are the simultaneously-proposed tag pairs of Proposed_features/Key:park:ownership and Proposed_features/Key:park:public_level, the latter of which especially overlaps significantly with this proposed feature. I am watching both. The main sticking point I have with this proposal is that it uses English and USA-centric text strings rather than the seemingly-better-thought-out (as they are currently in use) values that admin_level=* uses. As I've been pondering this for at least ten years in OSM, I'm pretty certain that we'll need numerical values (and what better than admin_level values? — they're already "figured out"!) rather than text strings. (I didn't have anything to do with the values for "ownership," even as I use them they seem too English and USA-centric). Still, eyes open, let's continue watching and having good dialog about these. Stevea (talk) 01:58, 10 September 2020 (UTC)

I agree with SteveA here about how park:type=* should probably be moved away from for better things like the ownership tags. That seems to be the general consensus also. As an interesting (or likely not, but whatever) historical fact I had originally created the park:type=* article because I thought it would be to tag the "type" of park. Which at the time I believed meant something like "neighborhood park", "pocket park", "Community Park", "mini park", and so on and so forth. It turned out though that the park:type tag was being used for something more akin to ownership status though. So, I quickly decided not to use the tag for "types" of parks. After more research I realized that's the problem with any and all whatever:type tags. "type" is ambiguous and we all have different ideas as to what it means. As an example, some people use boat:type to tag what type of boats places sell. The thing is, "type" could mean motor boat versus paddle boat, plastic versus wood, fishing versus "recreational" (whatever that means), Kayak versus sailboat etc etc. So, any type tag is not workable and they should all be depreciated in my opinion. Including park:type. There's really zero reason to use them. In this case you could just drop the word "type" the tag if you really wanted to and it wouldn't matter. It would probably make things less ambiguous.

As a side thing, while also agree with SteveA that "ownership" is a little to "English and USA-centric", I think the same the problem would go for admin_level. Although to a lesser degree, maybe, but I image some places in the world have parks that aren't in admin boundaries. There was actually just a thing I was watching that mentioned Philadelphia's (I think it was) city boundary is different then it's admin boundary (or something like that). That said, admin_level is still better then park:type, and while not perfect ownership would at least be a shorter leap IMO to whatever OSM eventually decides to go with eventually then just staying with park:type in the meantime until it materializes (including if that is admin_level). The good thing about OSM is that it is iterative and can involve intermittent steps between "horrible" and "perfect" (not that "perfect" exists though). Perhaps ownership could co-exist with admin_level also. You never know. They do seem slightly different. In the meantime though, lets at least not deal with this by adopting more whatever:type tags. --Adamant1 (talk) 02:38, 10 September 2020 (UTC)

I appreciate the agreement / harmony. However, as for "the same problem (too USA-centric) would go for admin_level," there is an existence proof that essentially shoots that down: admin_level and its myriad values is successful in a worldwide context (without English, simply numbers). Imagining (imaging?) "parks that aren't in admin boundaries" (I'm not quite sure what that means) needs some evidence, not imagining. With it, we can determine something we might have to back out of. Without it, hmm. And "something like that" in Philadelphia doesn't help similarly (or not similarly, as the case may be, as there isn't anything specific to compare against). I'm glad we agree that park:type should move towards deprecation (I myself have begun to deprecate MY use of it); we've done some solid work on acheiving that in the wiki we've both contributed to. The structure provided by admin_level is worldwide, established and ripe for this sort of leverage / piggybacking that is being proposed with park:public_level. It's a skeletal outline, though it has had years of thought behind it and in all that time, the concept has only strengthened in its ability to support parks like this. The park:type tag comparitively seems like it has run out of fuel and is stuck on the side of the road. Agreed: incremental iteration making OSM better is a welcome upward spiral of improvement. It might take years but ends up being worth the efforts. Yes, "perhaps ownership could co-exist with admin_level..." that's what ZeLonewolf and I (and I believe others, Adamant1 included) are trying to do. I'm not sure that this proposal (Viper444's) is "as developed." One problem I continue to have with it is that the scope key seems seriously overloaded with too many semantic markers (government-level, water, leisure / recreation...at least). To use ZeLonewolf's phrase, the "best of breed" emerging seems like what we're developing and polishing up to a bright shine. It's early in this process and it's great to read spirited Discussion. Stevea (talk) 06:34, 10 September 2020 (UTC)

I agree strongly with the others here. I especially think that the "county/state/regional/national" text names are US-centric would be a step backwards. Otherwise you'll find some place has a township, or a neighborhood park. Or another country with a totally different scheme that doesn't map at all. Is Scotland national or regional? etc etc. The admin_level=* scheme is really a good system for allowing different countries to tag various layers of government that might exist, and whatever we call the tags, the values should be somehow linked to that numeric scheme. We're really saying "this specific government administers this park" and using the numeric allows you to semantically link a park with an enclosing area tagged with that admin_level. ZeLonewolf (talk) 03:54, 10 September 2020 (UTC)

protected_area and other existing tag schemes

Thank you for taking a crack at fixing the way we tag parks and park-like things! I agree that the current scheme is messy and should be improved. I'm glad this is finally being discussed/worked on. I've been taking a near-simultaneous crack at cleaning up United_States/Public_lands which may or may not be helpful here (though it is of course USA-focused)

The proposal does not address what should be done with boundary=protected_area and protect_class=*. Those tags cover many (but likely not all) of these types of lands. You should clarify how this proposal would address the use of those tags. Is this additive to it? Or would it replace it?

Should we still use boundary=national_park? Or does this replace it?

Should we still use landuse=military? Or does this replace it?

ZeLonewolf (talk) 03:44, 10 September 2020 (UTC)

Possible solutions

Using park:type

It seems the best way around this would be to create separate park tag rather than having it nested under leisure Then the type would by the value of the park such as park=nature, park=mini, park=connecting

issues with ownership:

ownership doesn't always say what level something operates at. This is usually more often based on the operator type (level, class, category, kind, etc) We have a federal water reservoir for power operated as a county park. The ownership would not make sense in this case. Scope would seem to be a more applicable term.

"One problem I continue to have with it is that the scope key seems seriously overloaded with too many semantic markers (government-level, water, leisure / recreation...at least)"
Scope would only be used to describe who the facility/area is meant for. Local, community, neighborhood, city, region, territory, national, etc.

Yet this is still specific-country -centric (appears to be USA-centric to me). Earlier definitions of "scope" included water, leisure and recreation (just hours ago, they do not seem to now). The admin_level=* tag completely eliminates being "country-centric" by harmonizing all of the same values for a country, state (however "low" in the hierarchy you go) into specified numerical values. As long as you remain "at a certain scope" (I agree with you, the word "scope" is appealing) the value of admin_level and "a certain local semantic of what is meant by that" remains consistent. With text-based values (like city, territory, national...) this breaks down and isn't consistent. Stevea (talk) 09:57, 10 September 2020 (UTC)

I saw that I had not been concise and said that using scope with the others tag allowed all of those uses cases to be described. This gave the impression the scope was a factor in the activity. I removed the confusing line. Scope would only be used to describe who it is meant for. Viper444 (talk) 12:07, 10 September 2020 (UTC)

Attempting to predict how OSM end-users will use the data is pure folly. This is what is being attempted by saying "who it is meant for." By fragmenting "the public" into what you attempt to domain-restict with "scope," you appear to fall into the trap of acting as predictor of data usage and users' behavior. That crystal-ball prognostication can't be done and is a major fault in the logic of the proposal. (Not to mention its rapidly-shifting definitions and highly muddled propositions). Proposals such as these must be about crisp definitions of tagging syntax, not fanciful wishes as to renderer algorithmic calculations and re-definitions of re-definitions. For those reasons, I find it difficult if not impossible for me to continue considering this proposal. Stevea (talk) 12:18, 10 September 2020 (UTC)

I see your point, this is a rather large collection of concepts and it appears that the proposed feature page is more geared for the tagging of specific/individual map features. I will move this over to my personal talk page so that those interested can continue to follow along if they wish.
I think it is best to consider all of these things together however to keep things consistent. Then once a logical way is determined to classify everything the individual proposals could be refined and submitted.

As far as the rapidly shifting definitions and muddled propositions, this is simply a brainstorming session at this point. You have given a lot of valuable feedback already that I'll use to refine the details. If anything else this is to help myself better understand the logic behind the current tagging of these types of things and see if their is anyway to improve them. In the end I would like to get all of my fanciful wishes working in OSM as long as they make sense :) I hope you will continue to follow along provide any insights. Viper444 (talk) 00:47, 11 September 2020 (UTC)

on admin levels and US-centric terms

The admin level table does do a decent job of assigning common values to widely varying government organization units however it has it's flaws. Admin levels can vary within countries (seperate list for each us state) and have exceptions in some areas.

This is not a flaw, it is variation further "down" in the hierarchy, which is allowed and accommodated by the hierarchy of admin_level itself. Stevea (talk) 10:00, 10 September 2020 (UTC)

The government organization levels can change over time requiring reworking of the values. This is why I believe scope should be the term used in the area. I used US terms as that is where I am located however the terms would likely be different in another country. Canada may have scope=territorial or provincial for instance.

Yet, because OSM is international, you would have to re-define the terms for all countries. The admin_level=* tag has already solved that, so we should use it. Stevea (talk) 10:00, 10 September 2020 (UTC)

These terms would be associated with the admin_level depending on the country automatically (using the seperate osm wikidata database to automatically determine and update the values over time). That would be the ultimate goal. You type the admin level as it is called in you country and OSM automatically assigns the appropriate admin_level so it can render it correctly

I don't understand what "would happen automatically." Stevea (talk) 10:00, 10 September 2020 (UTC)

osm would automatically determine the appropriate admin level for the country based on the scope the user enters.

How? When? While I am editing? That's simply applying a key:value pair to an OSM datum. Are you proposing that rendering machinery implement what you propose? We are talking about tagging here, not auto-magically implemented renderer happenings. Stevea (talk) 11:59, 10 September 2020 (UTC)

"parks that aren't in admin boundaries"

What I meant was parks are not only boundaries. They are points of interest you go to/destinations. Boundary seems it would apply more to areas and regions places like parks are located within.

protected_area and other existing tag schemes

I apologize for not addressing these yet, however still working on putting the draft together :D As protected areas are also often points of interest, destinations, areas that require protection, management, etc and due to the fact there is a vast variety of these areas. I suggest replacing the boundary=protected_area with protected=* with the value being the type of protected area

boundary=national_park would also be replaced scope=national(term in this country) leisure=park or park=yes if using a new tag as mentioned above

The above two "suggestions" (replacing boundary=protected_area and boundary=national_park) simply will not happen in OSM: these tags are far too entrenched to be replaced. If the remainder of this proposal depends on either or both of those as a prerequisite, I cannot further consider this proposal. Stevea (talk) 10:36, 10 September 2020 (UTC)

The issue with boundary=protected_area is similar to that of having parks nested under leisure.

It takes away the ability to specify the kind of protected area without using an additional key.

The issue with boundary=national_park is similar. The kind of national park could be specified in the value but instead requires an additional key. It is also in a separate tag from parks which is not intuitive.

Based on your feedback I surprised to hear the contention with changing the way we go about tagging these. I'm not opposed to leaving the existing method in place, however, this seems to be the exact thing you were mentioning trying to avoid. By having them under boundary we are adding an additional tag that we don't need.

These tags could be used on new objects or in addition to existing objects without causing any issues that I can see. The renderer could simply continue to render the old tagging style until the new system was prevalent. The old tag combinations could then by converted to the new. Viper444 11:45, 10 September 2020 (UTC)

No contention, simply both the practicality of applying logic and the reality that an entrenched tag simply won't be changed as easily as your proposal seems to rather flippantly dismiss and replace with another scheme (which gets more muddled as it is re-written by the hour). By the way, "Viper444," as your moniker is red-linked, can you point to some of your edits, to vouch for your OSM experiences? I am always wary of red-linked wiki authors. Stevea (talk) 12:01, 10 September 2020 (UTC)

military areas would be tagged military=yes; military=base; military=training_grounds; etc.

I'll go back through and see if I missed anything, but that's what I can think of so far on those topics Thank you all for the feedback. I appreciate the insights and suggestions. Keep them coming please!

So much of this is unsigned (without four tildes) that it is difficult to follow. Especially because the User Page is redlinked, there is so much to not like about this proposal I don't know where to begin. It muddles together far too many ideas in a soft mishmash mess that blends network, ideas about what are meant by level of government and park all blended together into nonsense. I try to follow it yet it reads as poorly thrown together and not well thought out. Harsh? Yes. Honest? Yes. Stevea (talk) 23:08, 13 September 2020 (UTC)

Updates based on feedback

I agree the type is probably not a good descriptor and have removed all instance of it from the proposal. I've noticed that as a park, leisure is implied, so having it nested under leisure is pointless and eliminates the ability to define the kind of park. Therefore parks would get their own tag, as would many other kinds of features that are nested under leisure and other implied tags.

As far as using admin_level for each park and/or other entity. I think it may be the way to go for now. This would at least allow the values as they exist now to be reused while a way to link it all together in the background automatically is determined.

So for now you would add admin_level=* instead of, or in addition to the scope tag.

This will allow rendering based on the tag and the admin level. for example park=yes + admin_level=6 (any reason to use park level? may as well stick with the same) scope=county (optional)

later on, we could switch it to use scope and then remove the park_level tags

Updated proposal

I've updated the project with a new scheme and think I have it set up pretty well. Please take a look and let me know what you all think. I'm hoping to link together these projects where possible, taking the best ideas from each and finding what works. Hopefully we can eventually put together that has consensus and makes the most sense. Viper444 (talk) 11:22, 14 September 2020 (UTC)