Talk:Proposed features/Tag:boundary=aboriginal lands

From OpenStreetMap Wiki
Jump to navigation Jump to search


Use both tagging conventions after the vote?

One "solution" (to harmonize both tagging conventions) that hasn't been mentioned is to "move towards standardization" that OSM tag such entities with both tags. Today, we have an either-or approach. As long as both wikis documenting these usages reach consensus (to tag both) and this becomes widely practiced (perhaps after a bot run to do so), this could work. Stevea (talk) 20:41, 30 November 2018 (UTC)

Can you be more specific about what this tagging would actually look like? Currently, we have two options. The first option is a single tag boundary=aboriginal_lands (the subject of this proposal) and the other option requires two tags: boundary=protected_area + protect_class=24 (this is the alternative you refer to as the "existing" tagging scheme, although in practice it is only somewhat more common than the boundary=aboriginal_lands option in the database). Under this your proposal of using "both", would that mean we'd be required to use all three tags? Or do you propose requiring just two tags: boundary=protected_area + boundary=aboriginal_lands but and not using protect_class=24? I think for discussion of these proposals it's helpful to keep spelling things out. Just saying "both" but without clarifying specifically what you mean can be confusing. --Alan (talk) 22:37, 30 November 2018 (UTC)

Sure, Alan, happy to. I mean a Discussion ensues here (thanks for getting the ball rolling), part during the vote?, part after the vote about "what now?" By "both" I mean the existing Alternate as boundary=protected_area + protect_class=24 AND this proposal, boundary=aboriginal_lands. There might be a talk of a hemisphere split (and maybe that sharpens up into continents, Asia might need to run a bot or something), y'know, like that. Get worldwide consensus on what people expect, what people mean when they tag (the Australia and Canada segments are excellent stubs), these become a living wiki to describe the data.

A reason to include 24 going forward is the way it fits into the wider scheme of boundary=protected_area, as that is a real thing. I am heartened to see earlier (and functional) examples of render code, that's nice. And I see boundary=protected_area with other values get green Carto rendering. I've also seen proposals blurring of "hatching" rendering (old school 1980s style MacPaint styles, for example) and other clever proposals to help us "visually parse" ever-larger numbers of unique things. Visual parsing can and should grow in Carto, that's another topic. I do like that "these" (really "this," the single semantic) look like they can easily be rendered as the same thing, as they describe the same semantic. Let's make sure we wiki document for 24 "you can (should?) also tag boundary=aboriginal_lands to mean the same thing but OSM history and determining that admin_level=* for it was difficult, so this is best practice for today." Or something similar and very clear.

It may be that boundary=protected_area + protect_class=24 emerges towards "don't do it like this any longer" do it with boundary=aboriginal_lands instead (and its wiki entry points to the boundary=aboriginal_lands wiki). Many things are possible, a single one (and it's only a whisper) is what I'm calling "both" here. I am in a listening mode, too.

I am not suggesting boundary=aboriginal_lands and boundary=protected_area withOUT a protect_class=24 tag, as keeping the numerical tag "keeps it as a member of" having a protect_class tag, and associates an expected, sensible, already documented, fits-into-the-wider-existing scheme value. Finally (there might be a bit of "ongoing") we wiki-doc "do it like this" as politely as our wiki has become at doing. Stevea (talk) 22:57, 30 November 2018 (UTC)

Voting period closed

Does somebody wish to "call it?" I'd also like to continue the discussion above, w.r.t. "what now?" Stevea (talk) 17:28, 13 December 2018 (UTC)

It may be unorthodox of me to say it (I don't know how these votes work), yet I found 44 approve, 7 oppose, 1 vote was cast after the Vote End period. I'll characterize this as "overwhelming approval" with vocal opposition for several (reasonably well articulated) reasons. A suggestion forward is that our wiki reflect this by encouraging use of boundary=aboriginal_lands, with a link to the protected_area=* and protect_class=24 wiki sections. Those can be (should be) updated in real time like any good (living) wiki. The question becomes what to do with the parallel existing tagging scheme of two tagging styles (one with one tag, one with two) meaning the same thing. We seem to agree these should be rendered identically: boundary=protected_area + protect_class=24 and boundary=aboriginal_lands (this tag). Alan and today's Usage Statistics call this dual-tagging "somewhat more common" (true) and the stats show numbers in the low- to mid-hundreds (for each tagging style). Those number are "sort of small" but also "large enough to cause confusion" or "missed data queries" or just plain "misunderstandings because of legacy/different tagging." Perhaps we leave it there for a future day. Perhaps there is more discussion here, like how to merge the older scheme into the newer one, towards this tag being "the" way (preferred, this vote demonstrates some of that) rather than "another" or "a minority in 2018" or "a majority in 2019" (or 2020s) method. Factually, there is a sort of cleavage between Northern Hemisphere (largely with this tag, though "slightly fewer examples") and Southern Hemisphere (with strong representation in Brazil/South America and Australasia) using the dual-tagging method. To me, it seems easiest to (eventually) deprecate the dual-tagging method in preference of this one, with some wiki at boundary and 24 explaining this. In my opinion, this vote and how it was a productive dialog shows how we do things in OSM: largely a lot of agreement mixed in with a bit of legacy and a peer ahead towards how we'll do things better in the future. Alan, anything to say or do here now/next? Stevea (talk) 22:40, 13 December 2018 (UTC)

You're right that the time is up and there's "overwhelming" support. I changed the page to "approved" status and created the approved tag page: boundary=aboriginal_lands. Everyone please feel free to flesh it out (and translate it!). As for what to do next, IMO I'd like to see what happens once we get the rendering approved (and I still need to do more work adjusting colors before that is ready). And then I'd like to hopefully bring some more Brazilians into the discussion to see if they really want to keep using the boundary=protected_area + protect_class=24 or if they want to switch to boundary=aboriginal_lands. And if people do start to switch, then maybe at some later date we can propose to deprecate the dual tag approach. But I don't feel the need to push that discussion at this point. If someone else wants to lead that discussion, it's fine with me. --Alan (talk) 23:22, 13 December 2018 (UTC)
Excellent. Stevea (talk) 23:27, 13 December 2018 (UTC)
Oh, there's one more thing to put into the "what's next" queue. At some point I'd like to revisit the comment from Adamrecvlohe who suggested that we need some additional tags to distinguish between different types of aboriginal lands. Possibly something like aboriginal_lands=trust_lands, aboriginal_lands=reservation, and aboriginal_lands=shared_jurisdiction. We'd need to have a thorough discussion about these with some experts from multiple countries to make sure we've got most of the use cases covered. That might be better suited to the mailing list. Also there's no rush to get started on that, either. --Alan (talk) 20:21, 14 December 2018 (UTC)
I applaud your suggestions and our future efforts to get this as correct as we can, however, what you suggest is almost as large a topic as this vote/tagging scheme itself! (Large and complex problems in OSM haven't stopped us from more-or-less solving them in the past, though). In my contributions to United_States_admin_level#Native_American_reservations (and so this part is USA-specific) I mention that "A complication are state recognized tribes in the US, as individual sovereign states recognize these tribes while the (federal) US Bureau of Indian Affairs does not. Also, specific distinctions should respect the unique entities of Hawaiian home land, Alaska Native tribal entities, Pueblo and Off-reservation trust land." So, this is a highly complex topic and I believe must be handled on a country-by-country basis for each country with aboriginal lands. Perhaps we can combine the "conversations" with Brazilians (et al) with not only if they want to keep the "other" method of tagging, but this newer "what's next" topic of "different types" in each country. Let's roll up our sleeves, this will be a fair bit of effort! Stevea (talk) 20:37, 14 December 2018 (UTC)
If this is "a" or "the" place where continuing boundary=aboriginal_lands discussion and its logical difficulties of harmonizing with admin_level=* is to take place, I don't want important comments made by Minh Nguyễn 💬 to get lost. He said in his Vote section: "If there are any cases where these areas also form administrative areas that fit into the admin_level=* hierarchy, the ways or relations forming the boundary=aboriginal_lands area could be added to a separate administrative boundary relation." That is an excellent (imo) consideration / potential solution for when both boundary=aboriginal_lands and admin_level=* need to be considered together, but the identified tagging difficulties would otherwise prove troublesome. Stevea (talk) 20:06, 20 December 2018 (UTC)

Movement towards the deprecation of protect_class=24

As a Contributor who has followed the simultaneous growth of boundary=aboriginal_lands with its equivalent of boundary=protected_area + protect_class=24 AND as I agree (publicly, here, now) with this proposal to eventually deprecate the protect_class=* key, I support boundary=aboriginal_lands instead of boundary=protected_area + protect_class=24 in all instances. I fully support a movement towards the eventual deprecation of protect_class=24. Stevea (talk) 22:48, 4 November 2020 (UTC)