Proposal:Tag:boundary=aboriginal lands
boundary=aboriginal_lands | |
---|---|
Proposal status: | Approved (active) |
Proposed by: | Acrosscanadatrails |
Tagging: | boundary=aboriginal_lands |
Applies to: | |
Definition: | Tagging the boundary of aboriginal lands. |
Statistics: |
|
Rendered as: | TBD (see proposal on github) |
Draft started: | 2010-03-11 |
RFC start: | 2008-06-25 |
Vote start: | 2018-11-24 |
Vote end: | 2018-12-08 |
TAG HAS BEEN APPROVED. There were 45 votes in favor and 7 against. The record of the voting is at the bottom of this page. To view the approved tag page, go here: boundary=aboriginal_lands.
Proposal
This proposal is for mapping the official reservation boundaries of recognized aboriginal / indigenous / native peoples. These areas go by a variety of names in different countries, such as Indigenous Protected Areas in Australia, Indian Reserves in Canada, Indian Reservations in the United States, Terra Indígena (Indigenous Territory) in Brazil, Territorio Indigena in Colombia, or Territory of Traditional Natural Resource Use in Russia, to name some common examples.
While the specific status of these areas differs by country, they generally share two things in common:
- These regions have special legal status for the benefit of aboriginal peoples, and different laws may be enforced within these regions. The aboriginal groups usually have some form of self-governance in these areas.
- These regions are mutually recognized between the aboriginal peoples and the occupying/colonizing government, and their boundaries are not in dispute. (The fact that some aboriginal groups may claim much larger areas and may be negotiating for an expansion of their reservations does not change the fact that the existing boundaries are mutually recognized as the current legal situation).
This proposal does not cover:
- Larger land claims that have not yet been mutually finalized between the aboriginal group and the occupying/colonizing government. In many countries, notably in parts of Canada, treaty negotiations are ongoing. These disputed areas should not be mapped using the boundary=aboriginal_lands tag.
- Lands outside of reservations that are owned by aboriginal groups, but which do not have special legal status. In these areas, the aboriginal groups act as a landowner like any other landowner. OpenStreetMap does not map land ownership.
- Areas outside of reservations where aboriginal groups may have special rights, such as traditional fishing or hunting grounds.
- The traditional or pre-colonial lands of aboriginal people. These may be appropriate for Open Historical Map, but they cannot be accurately mapped or verified within OpenStreetMap. For a good map of traditional aboriginal territories around the world, see https://native-land.ca/.
Tagging
Required:
Use boundary=aboriginal_lands to mark the jurisdiction area.
Optional:
Add the tag place=region only if
- population=number of people living in the reserve is known.
- size=area in square km is known, and a census was gathered from the source.
Add wikipedia=* to link Wikipedia article about this specific reserve if it is available.
Add description=description of the reserve to help further identify it.
Add url=[web site of the reserve ''web site of the reserve''] if it is available
Add image=an http://.... .jpg link to a picture to show what the reserve looks like
Terminology
There are multiple words in English used to describe aboriginal people. These terms vary by country, and often several different terms are used even within the same country. Terms such as "native", "indigenous", "first nations", "indian", and "aboriginal" are sometimes but not always as synonyms of one another. For the purposes of this proposed tag, "aboriginal" is meant to be a neutral term, but it also a somewhat arbitrary choice.
Specific terminology in Canada
Wikipedia:Aboriginal peoples in Canada comprise the First Nations, Inuit and Métis. The descriptors "Indian" and "Eskimo" are falling into disuse. Old Crow Flats and Bluefish Caves are the earliest archaeological sites of human habitation in Canada. The Paleo-Indian Clovis, Plano cultures and Pre-Dorset pre-date American indigenous and Inuit cultures. Projectile point tools, spears, pottery, bangles, chisels and scrapers mark archaeological sites, thus distinguishing cultural periods, traditions and lithic reduction styles.
Specific terminology in Australia
In Australia, there are two Indigenous peoples - the Aboriginal (not aboriginal) peoples & the Torres Straight Islanders. To quote from the Australian Human Rights Commission:
The 'A' in 'Aboriginal' is capitalised similar to other designations like 'Australian', 'Arabic' or 'Nordic'. The word 'aboriginal with a lowercase 'a' refers to an indigenous person from any part of the world. As such, it does not necessarily refer to the Aboriginal people of Australia.
'Aboriginal people' is a collective name for the original people of Australia and their descendants, and does not emphasise the diversity of languages, cultural practices and spiritual beliefs. This diversity is acknowledged by adding an 's' to 'people' ('Aboriginal peoples'). 'Aboriginal people' can also be used to refer to more than one Aboriginal person.
The 'I' in 'Indigenous' is capitalised when referring specifically to Australian Aboriginal and Torres Strait Islander peoples. The lower case 'i' for 'indigenous' is only used when referring to people originating in more than one region or country such as the Pacific region, Asiatic region, Canada or New Zealand"
Wikidata
At Wikidata the concept lands inhabited by indigenous peoples is commom to all cited types: "Indigenous Protected Areas", "Indian Reserves", "Indian Reservations", "Indigenous Territory", etc.
Rejected tagging ideas (proposed deprecated tags)
The boundary=administrative does not work since some aboriginal lands are equivalent in jurisdiction to province and others to country. So therefore, an aboriginal lands admin_level=* is not equivalent to a numerical value.
Also, the border_type=native_reserve or territorial is not needed, because the the tag for boundaries boundary=* already marks the borders of areas, mostly political, but also of other administrative areas.
Some mappers have been using the combination of a boundary relation using boundary=administrative and boundary:type=aboriginal_lands (example). This proposal suggests that we deprecate that style of tagging and adopt the simpler use of the single tag boundary=aboriginal_lands
Alternate tagging approach
The combination of boundary=protected_area and protect_class=24 is also used in OSM. Both are used for the same purpose. If the boundary=aboriginal_lands proposal is rejected, then using this alternate proposal would be sufficient. However, there is some value in a simpler, more intuitive tag instead of the more awkward combination of two tags for such an important feature. Should this vote be Approved, it remains to be seen whether both tagging conventions remain or whether OSM might further reach consensus that boundary=protected_area and protect_class=24 be deprecated in the interest of simplicity: having one tag represent this single semantic. (Even as it differs slightly in different world regions). Perhaps (should the vote be Approved) we keep both, allowing boundary=protected_area and protect_class=24 to be used for a "particularly local" flavor of boundary=aboriginal_lands in a particular locality. Or, perhaps not, where consensus agrees that having one tag is preferred, and "boundary=aboriginal_lands means locally what it means locally." Or even "used specifically where it is used to mean what it means right there." Sometimes (as in the present situation) there is more than one place to look for the data you may be interested in: today, one must do (at least) two queries, what you receive in reply is "the data in OSM right now." Seems both obvious and important to say that in these circumstances.
More Discussion of at least one solution ("tag with both this proposal and the alternate").
Sample Areas
Here are some areas already mapped as boundary=aboriginal_lands:
- Yakama Indian Reservation https://www.openstreetmap.org/relation/7320420
- Westbank First Nation https://www.openstreetmap.org/way/159693426
Sample Rendering
Usage Statistics
Overpass query for boundary=aboriginal_lands: http://overpass-turbo.eu/s/DV4
Overpass query for protect_class=24 (alternate tagging proposal): http://overpass-turbo.eu/s/DV5
Discussions
from https://wiki.openstreetmap.org/wiki/Talk:Key:boundary#First_Nations
In Canada some areas of land are designated as Indian Reserves, held in trust for First Nation bands. Some of these lands cross provincial borders and even cross the U.S. border (see Akwesasne )
Suggestion: First Nations and Indian Reservations should be boundary=administrative; admin_level=1; border_type=first_nation; as they are international.
- Should borders like this really be administrative? Certainly using admin_level=1 for this just looks wrong to me... --Eimai 17:22, 25 June 2008 (UTC)
- I agree with Eimai. If they are international borders, they should be treated as admin_level=2 just like other international borders. --Hawke 05:48, 26 June 2008 (UTC)
I would suggest that we remove these from admin_level=1, and use something else instead. We now have a boundary=national_park, which arguably has some administrative function. In the same way as the various equivalents of "National Parks" in other countries, these cross various administrative boundaries, and should probably be considered as being orthogonal to county and state-level borders. For example, the Brecon Beacons National Park includes land in no fewer than nine counties. boundary=indian_reserve perhaps? Chriscf 11:57, 3 December 2008 (UTC)
- It can also apply to other native people, such as the Masaai in Kenya/Tanzania or the Samii in Norway/Sweeden/Finland/Russia. boundary=native_reserve or boundary=native_nation is probably better. But I fully support removing them from boundary=administrative. Let admin_level=1 be reserved for supernational administrative borders such as the European union. --Skippern 13:15, 3 December 2008 (UTC)
- I agree with Eimai ... Skippern. In spite of the great respect I can have for those Nations and Peoples... There are other solution, like the Skippern's one. FrViPofm
- All, ok how's this boundary=native_reserve; border_type=territorial; place=region; name=*; admin_level=2 Maybe this should cover all grounds.--acrosscanadatrails 12:37, 11 March 2010 (UTC)
- boundary=native_reserve; border_type=territorial; place=region/county/city whatever that fits; name=*; description=description of the reserve; www=web site of the reserve, if any; wikipedia=wiki article about the people living on the reserve; population=number of people living in the reserve; and do not forget source=*. I think admin_level is not suitable for such reserves. --Skippern 13:14, 11 March 2010 (UTC)
With some time to think about it, this tag proposal page should be changed to boundary:type=aboriginal_lands. Here's why:
- admin_level=4 -- because it has its own jurisdiction which is similar to a 'state/province' level, where it is still within a country (generally) more times than not. There are special cases (just like countries that are in transition & dispute). In some countries there are signed agreements with members of each group.
- place=state -- this should also be used, as it clearly defines the fact that it is like a State/Province jurisdiction and more clearly defines the admin_level, where admin_level=4 could be used for boundary=national_park https://www.openstreetmap.org/browse/way/40060616
- boundary=administrative -- because this is an 'administrative' boundary. Where it's known, and sometimes signed, as it would be trespassing if there is no implied visiting (there is no security check to go/through the area)
- boundary:type=aboriginal_lands -- although this is not documented (yet), it is a way to clearly list what type of boundary this is
- landuse=reserve -- in OSM, both the landuse and drawing the actual property line is used interchangeably. In this case. the default landuse would be the fact that the whole are is a reserve. When more details are known, these can also be mapped; Listing the physical environment, such as 'natural=wood' natural=grass natural=water.
--acrosscanadatrails 16:02, 12 May 2010 (UTC)
- I disagree, This would imply that, for instance, Cowichan 1 is not part of British Columbia and is a province in its own right. It doesn't even have its own government but is rather just one of 9 reserves in the Cowichan Tribes, and Cowichan Tribes as a whole is more comparable to a municipality in its scope than a province. I would give Cowichan tribes as a whole an admin level of 7 or 8, and Cowichan 1 no higher than 9. Landuse seems inappropriate as being part of a reserve doesn't imply any particular use of the land and many specific land uses can occur; Cowichan 1 has residential, commercial, farmland, industrial, forestry, and unused land. And what exactly would place=boundary:type be as distinct from straight boundary=*? --Hai-Etlik 01:47, 1 July 2010 (UTC)
- The use of landuse=reserve would mean that you could not have part of the land used for farming, residences etc. Some aboriginal areas do get used for multiple things in different sections. boundary=aboriginal_lands clearly sets this aside from other boundaries as it should be. Warin61 (talk) 06:31, 6 November 2016 (UTC)
- I agree with boundary:type=aboriginal_lands. The boundary is "administrative", and should be labeled as such. The landuse key should be reserved for land uses within the reserve, like differentiating farmland from residential land. In Canada and USA, areas that are largely self-governing would use admin_level=5 because they are technically part of the surrounding province/state for some purposes, even though they are exempt from many of its laws. Some aboriginals lands would instead have the same admin levels as municipalities. If the land title is held by the aboriginal group but follows county laws, then it would only have admin_level=10. --Arctic.gnome (talk) 15:23, 16 July 2018 (UTC)
- The value admin_level=5 is not appropriate for these "aboriginal lands" in the USA. By wide consensus (see United_States_admin_level#Consolidated_city-counties.2C_Independent_cities and United_States_admin_level#cite_note-6) this value is reserved for New York City, a unique case of " NYC is the US's only "consolidated city-county of multiple counties" (or county equivalents), so we tag it admin_level=5. If other CCCs grow by agglomerating entire multiple counties, these new multiple-county CCCs can promote from admin_level=6 to admin_level=5 to be consistent with NYC (see Discussion). "Tag twice" such multiple-county CCCs: for NYC, admin_level=5 on the consolidated city and admin_level=6 on each borough (county or county equivalent). It does not seem possilbe (by wide consensus and the logic/math of it) that ANY admin_level=* can be used for aboriginal_lands, at least in the USA's rather complex hierarchy, as aboriginal_lands (as we call them in this wiki, in the USA they are commonly called "Indian Reservations" although "Native American" is a more sensitive term, I have learned) have "parallel sovereignty" (with nations, states, counties and cities) and thus do not fit into this scheme. So while boundary=administrative remains a semantically accurate designation (though without a clear-cut admin_level=* value, it remains incomplete), at least boundary=aboriginal_lands stays with the same key value, much like boundary=census, which is also discouraged from being associated with an admin_level=* tag, with any value. We do get closer to consensus with good discussion like this. Stevea (talk) 18:00, 30 November 2018 (UTC)
See also
Taginfo map of boundary=aboriginal_lands: http://overpass-turbo.eu/s/sji
Alternate tagging proposal: boundary=protected_area + protect_class=24
Taginfo map of boundary=protected_area + protect_class=24: http://overpass-turbo.eu/s/DV5
An obsolete proposal for admin_level=aboriginal_land
https://wiki.openstreetmap.org/wiki/Geobase/Canadian_Aboriginal_Lands
http://en.wikipedia.org/wiki/Aboriginal_peoples_in_Canada
http://en.wikipedia.org/wiki/Jay_treaty#Native_American_rights
http://en.wikipedia.org/wiki/Indian_reserve
Voting
Voting on this proposal has been closed.
The result is approved/rejected with 45 votes for and 7 votes against.
- I approve this proposal. EneaSuper (talk) 10:51, 4 December 2018 (UTC)
- I approve this proposal. Yep, it's about time ;) --Henke54 (talk) 17:32, 26 November 2018 (UTC)
- I approve this proposal. It's true that boundary=protected_area + protect_class=24 would be workable, but I think it's too clunky and non-intuitive. It also limits the possibility of adding additional subtags if we find we need to distinguish different subtypes of aboriginal_lands in the future. --Alan (talk) 00:34, 25 November 2018 (UTC)
- Hi Alan: You say "limits the possibility of additional subtags" yet OSM did just that with protect_class=1a and protect_class=1b and with a simple wiki table entry so documenting, this works and it is what we use today. Stevea (talk) 20:33, 28 November 2018 (UTC)
- I oppose this proposal. If a place like Crimea isn't a big enough mess, now add the borders of people that had no written history, no ability to survey and no concept of borders. Who did they conquer to "own" their land? Aren't you doing a disservice to those conquered before? I vote no. --Br10ta10 (talk) 02:46, 25 November 2018 (UTC)
- I'm not sure if you're being serious or not (and I note that there is no OSM user with your corresponding username) but this has nothing to do with Crimea. Note, even though it's true that the tag is "aboriginal_lands", and in some sense all of the precolonial territory of the Americas and Australia is aboriginal land, here we're specifically talking about native reservations. We are not trying to map any traditional or pre-colonial borders with this proposal. The boundaries of these reservations are legally defined and generally recognized by both sides, the native groups themselves, and the colonizing powers. These boundaries are very much not in dispute, unlike the case of Crimea. --Alan (talk) 03:29, 25 November 2018 (UTC)
- I approve this proposal. As it is strictly preferable over numerical codes required by protect_class
There should be at least short description what is actually mapped by this tag. I hope that it is sort of official documented borders but I prefer to be sure.--Mateusz Konieczny (talk) 10:41, 25 November 2018 (UTC)
- To Br10ta10 and Mateusz Konieczny, you are both correct that despite my attempted cleanup of the proposal, there still wasn't a good description of what these features actually are in the real world. I added a new description at the top of the page. That's my fault, sorry that I didn't include that before I started the vote. --Alan (talk) 18:00, 25 November 2018 (UTC)
- I approve this proposal. This is an incredibly important issue that I believe OSM should have adapted a long time ago and I'm really happy to see that it's finally being addressed! --AlyD_VT (talk) 05:15, 25 November 2018 (UTC)
- I approve this proposal. I agree with Alan that boundary=protected_area + protect_class=24 is sub-optimal in terms of human factors. This is much more intuitive. --Brian de Ford (talk) 19:08, 25 November 2018 (UTC)
- I approve this proposal. Thanks Alan for putting this up to a vote - much needed. Glassman (talk) 20:39, 25 November 2018 (UTC)
- I approve this proposal. --SelfishSeahorse (talk) 21:45, 25 November 2018 (UTC)
- I oppose this proposal. I prefer boundary=protected_area, more general and flexible --Waldhans (talk) 10:35, 26 November 2018 (UTC)
- I approve this proposal. This is a great addition and a good example of something that can be addressed for each local OSM community differently. For the US, at least, this is a clear legal and administrative boundary that is missing. --Samlibby (talk) 15:04, 26 November 2018 (UTC)
- I oppose this proposal. Boundary=protected_area has this covered, and IMHO is just as easy to use. If we start introducing distinct specific boundary=* tags for all the various types of protected areas across all countries, where does it stop? And will carto now be lobbied to render boundary=aboriginal_lands (with its few hundred uses) ahead of boundary=protected_area (with 70,000)? If aboriginal_lands need recognition in OSM as a special entity with sovereign rights (which I totally understand), then they should get their own administrative boundary type, and be defined as such. This is orthogonal to their designation as a type of protected_area. If we want to increase the relevance of OSM to the outside world, we should support widely recognized formal schemes such as IUCN protected areas. --Doug sfba (talk) 15:42, 26 November 2018 (UTC)
- "protect_class=24" is far from being human readable Mateusz Konieczny (talk) 16:24, 26 November 2018 (UTC)
- Mateusz, that's the purpose of the protection_title=* tag, which will allow any country-dependent special name to be added for human readability. --Doug sfba (talk) 22:32, 26 November 2018 (UTC)
- Doug sfba, both tags can co-exist. There is currently a proposal to render both boundary=aboriginal_lands AND protect_class=24 with the same style in Openstreetmap-carto (the "standard" map on the main OSM page). --Jeisenbe (talk) 12:09, 29 November 2018 (UTC)
- Doug, these ARE administrative boundaries (we agree), but because of the complexities of multiple levels of interaction they have with other governments (often with "surrounding" administrative boundaries) fitting these into the simplistic hierarchy of admin_level=*, try as OSM might to accommodate that, it simply does not work (logically/mathematically). We are both voting No on this, me largely because of the redundancy of existing tagging and knowing that an admin_level=* solution is not forthcoming. As an admin_level=* solution seems to be going, going (gone?), what remains to be seen is how these two tagging conventions coexist in the future. This vote provides us with important dialog which can help us reach better consensus about that. Emerging is that both might be rendered with the same "look" in Carto. What isn't yet decided is whether the "24" flavor remains as a tagging convention in OSM or becomes deprecated by this Proposal, should it pass. Either way, a brief history (admin_level=* would be ideal, but is unworkable, so these two tagging conventions have emerged...) should be documented in our wiki (for both, should both survive), explaining "best usage" for one, the other, or both. Stevea (talk) 18:39, 29 November 2018 (UTC)
- Doug sfba, both tags can co-exist. There is currently a proposal to render both boundary=aboriginal_lands AND protect_class=24 with the same style in Openstreetmap-carto (the "standard" map on the main OSM page). --Jeisenbe (talk) 12:09, 29 November 2018 (UTC)
- Mateusz, that's the purpose of the protection_title=* tag, which will allow any country-dependent special name to be added for human readability. --Doug sfba (talk) 22:32, 26 November 2018 (UTC)
- I approve this proposal. --Zlavergne (talk) 16:16, 26 November 2018 (UTC)
- I approve this proposal. Very nice work by Alan moving this forward, and (more than) demonstrating that it is suitable for inclusion in the Carto-CSS style. I also fully agree with Mateusz Konieczny that a meaningful tag value is far better than a numeric code as in the protect class tagging. It not only reflects the original goals of OSM tagging, but is far easier to find & use. SK53 (talk) 16:40, 26 November 2018 (UTC)
- I approve this proposal. Lookup tables like protect_class=* are not user-friendly for editing, and "social-protected area" is a really bad category to put sovereign, self-governing entities into. Every other value of that tag describes resources that are protected for the benefit of some other entity. --Dericke (talk) 17:35, 26 November 2018 (UTC)
- I oppose this proposal. The existing tagging scheme is fine, documented and is not onerous or unfriendly in any way. However, this is not the solution. The reason is that as we collide in the namespace of boundary=* with what are actually boundary=administrative entities, we are creating here an "other" value for what already exists (an administrative boundary, a boundary=protected_area). We still have not "solved" (despite many attempts at consensus) what to do with admin_level=* on these truly boundary=administrative entities. I'm not optimistic we will (we might), but this is not the correct solution. --Stevea (talk) 00:06, 27 November 2018 (UTC)
- This was initially my view as well, but the lands covered under this proposal have complex relationships to other boundary=administrative features. For example, in the US, Indian Reservations typically function as admin_level=4 and are sovereign in most respects from the jurisdiction of states. However, state boundaries still overlap these reservations, even though the state has little to no authority within them. If a reservation had one default speed limit and the enclosing state had a different one, how would routing software interpret two overlapping boundaries with the same admin_level? By having a different value for boundary=*, data consumers could have a rule that, within the US, a boundary=aboriginal_lands supersedes an overlapping boundary=administrative with the same admin_level. Other countries with differing relationships between the aboriginal territory and the national government could have their own rules. These territories are significantly different from all other types of protected_area, in ways which are politically sensitive, which is why I don't think that tagging is an adequate solution either. --Dericke (talk) 20:38, 27 November 2018 (UTC)
- I understand the complexity, I have contributed to the admin_level discussion in the USA and wrote some of its wiki, including the distinct complication that there are US states (admin_level=4) which have state-level reservations not recognized by the federal government (admin_level=2). However, what I hear as your reasoning is not "tag data as actual data" but rather "we can fix this in renderers and with 'rules' in routing software." There being so many renderers and routers, this is a major reason we say "don't tag for these." We might either say that "these entities simply do not fit into the hierarchical namespace of admin_level" (as their interrelated relationships are too complex) or we solve an admin_level=* problem solely within admin_level=*. Given the "parallel sovereignty" which simply stated cannot be captured in a single hierarchy (or if it can, I haven't seen it proposed yet) we must go outside of admin_level=*. We already have with boundary=protected_area + protect_class=24 as it is a correct designation, fitting into an existing scheme. To solve your (instant) problem, simply apply the routing rules about speed limits to the existing and documented tagging scheme. Inventing a new tag gains us little to nothing, imo, simply replacing what we already have with some "syntactic sugar." Stevea (talk) 19:44, 28 November 2018 (UTC)
- Myself and others have shared our reasons, here and on the mailing list, why we don't find protected_area to be adequate for reservations. I would like to read your response to those arguments.
- I understand the complexity, I have contributed to the admin_level discussion in the USA and wrote some of its wiki, including the distinct complication that there are US states (admin_level=4) which have state-level reservations not recognized by the federal government (admin_level=2). However, what I hear as your reasoning is not "tag data as actual data" but rather "we can fix this in renderers and with 'rules' in routing software." There being so many renderers and routers, this is a major reason we say "don't tag for these." We might either say that "these entities simply do not fit into the hierarchical namespace of admin_level" (as their interrelated relationships are too complex) or we solve an admin_level=* problem solely within admin_level=*. Given the "parallel sovereignty" which simply stated cannot be captured in a single hierarchy (or if it can, I haven't seen it proposed yet) we must go outside of admin_level=*. We already have with boundary=protected_area + protect_class=24 as it is a correct designation, fitting into an existing scheme. To solve your (instant) problem, simply apply the routing rules about speed limits to the existing and documented tagging scheme. Inventing a new tag gains us little to nothing, imo, simply replacing what we already have with some "syntactic sugar." Stevea (talk) 19:44, 28 November 2018 (UTC)
- This was initially my view as well, but the lands covered under this proposal have complex relationships to other boundary=administrative features. For example, in the US, Indian Reservations typically function as admin_level=4 and are sovereign in most respects from the jurisdiction of states. However, state boundaries still overlap these reservations, even though the state has little to no authority within them. If a reservation had one default speed limit and the enclosing state had a different one, how would routing software interpret two overlapping boundaries with the same admin_level? By having a different value for boundary=*, data consumers could have a rule that, within the US, a boundary=aboriginal_lands supersedes an overlapping boundary=administrative with the same admin_level. Other countries with differing relationships between the aboriginal territory and the national government could have their own rules. These territories are significantly different from all other types of protected_area, in ways which are politically sensitive, which is why I don't think that tagging is an adequate solution either. --Dericke (talk) 20:38, 27 November 2018 (UTC)
- If you think that I am advocating for "we can fix this in renderers and with 'rules' in routing software", then clearly I choose an example that was too distracting. My point was that there is a logical contradiction inherent in overlapping boundaries of the same admin_level. You went on to explain the problem better than I could, so we are clearly in agreement there. I think it's worth stating that the rule is "don't tag for the renderer." That is, don't map around the constraints of a specific consumer of data. If someone uses a renderer that is imaginary within an example, then they are almost certainly not advocating tagging for the renderer. --Dericke (talk) 20:53, 28 November 2018 (UTC)
- I'm not here to argue, I'm here to vote and to state my reasons for doing so. Additionally, I have both stated some facts about how OSM does things right now (viz my comment to Alan near the top) and sprinkled some history, observation and my opinion where I thought it appropriate to share the basis behind my reasoning. Stevea (talk) 21:12, 28 November 2018 (UTC)
- I approve this proposal. --Neuhausr (talk) 04:08, 27 November 2018 (UTC)
- I approve this proposal. Lumping aboriginal_lands with other “protected lands” like state forests shows a lack of sensitivity or understanding of the unique administrative and cultural role these territories serve. —Mizmay (talk) 02:44, 28 November 2018 (UTC)
- I oppose this proposal. As a Cherokee, my view is this is another form of political boundary and ideally falls under boundary=administrative. Paul Johnson (talk) 21:23, 28 November 2018 (UTC)
- Paul Johnson, can you clarify what the boundary=administrative tagging approach would look like? What admin_level=* would we use in that case? The problem with boundary=administrative is that it requires a nested hierarchy of levels, and aboriginal areas sometimes exist outside of that hierarchy, and sometimes even cross national boundaries. --Alan (talk) 02:50, 29 November 2018 (UTC)
- First Nations territories in Canada are typically tagged with a level of 5 (boundary=administrative). In practice, I think it generally makes sense in Canada to tag Tribal Councils as 5, and the Nations themselves as 6, but some Nations aren't part of Councils, so it should be done on a case-by-case basis based on the degree of autonomy and authority the Nation has. In Canada, the First Nations fall under provincial jurisdiction for the most part, that's why that admin level makes sense. Things are different in other places. Part of the problem with boundary=aboriginal_lands is that it interferes with the ability to be clear about the manner in which that region is administratively distinct from its surroundings. --Alan Trick (talk) 21:22, 2 December 2018 (UTC)
- See https://lists.openstreetmap.org/pipermail/tagging/2018-November/041156.html. Paul Johnson (talk) 03:03, 29 November 2018 (UTC)
- It seems safe to say there is some consensus that using admin_level=* on these lands is fraught with difficulty if not mathematical impossibility: they don't map onto the existing hierarchy, which does not accommodate the kind of "parallel sovereignty" found in North America (USA, perhaps similar in Canada). I (and others) also say "yet, fixing it like this duplicates something we already do." I'm OK with this "we already do this" convention with two tags, it is correct as we have documented its scheme. Some feel this proposal is an improvement on the two-tag convention. But I don't think this is going to be solved with admin_level=* or else it would have been by now. Stevea (talk) 03:39, 29 November 2018 (UTC)
- Thank you both. Let me try to rephrase and summarize for the benefit of people following along and for subsequent voters. I see you have two different objections. Stevea and a few others are arguing that boundary=protected_area + protect_class=24 is sufficient (and I assume by extension that you support some kind of unique map rendering for these areas, perhaps the brown outline currently proposed, and not the green currently in use for other protected areas). On the other hand, Paul Johnson argues that there should be no special tag for aboriginal areas and that they should use boundary=administrative, potentially with admin_level=3 or similar. Paul also argues that these areas should be rendered as any other administrative boundary without any special-case rendering. As far as I can tell, those are the only two alternatives to boundary=aboriginal_lands that have been suggested. Hopefully any subsequent voters who choose to vote no would indicate which of these alternatives they prefer? --Alan (talk) 04:17, 29 November 2018 (UTC)
- Thanks for the summary, Alan. I support seeing boundary=protected_area + protect_class=24 — or any or all protected_areas, though this is again fraught with difficulty, given their number — rendered in Carto. Eventually rendering OSM's data does seem an objective, at least some or most of the time! Perhaps I walk a knife-edge by saying this, but I don't wish to argue here, merely express my vote and reasoning. Stevea (talk) 04:30, 29 November 2018 (UTC)
- It seems safe to say there is some consensus that using admin_level=* on these lands is fraught with difficulty if not mathematical impossibility: they don't map onto the existing hierarchy, which does not accommodate the kind of "parallel sovereignty" found in North America (USA, perhaps similar in Canada). I (and others) also say "yet, fixing it like this duplicates something we already do." I'm OK with this "we already do this" convention with two tags, it is correct as we have documented its scheme. Some feel this proposal is an improvement on the two-tag convention. But I don't think this is going to be solved with admin_level=* or else it would have been by now. Stevea (talk) 03:39, 29 November 2018 (UTC)
- Paul Johnson, can you clarify what the boundary=administrative tagging approach would look like? What admin_level=* would we use in that case? The problem with boundary=administrative is that it requires a nested hierarchy of levels, and aboriginal areas sometimes exist outside of that hierarchy, and sometimes even cross national boundaries. --Alan (talk) 02:50, 29 November 2018 (UTC)
- I approve this proposal. This proposal is a good idea for North America. Boundary=Administrative won't work because there is no appropriate admin_level, and there is no reason to use boundary=administrative plus administrative=aboriginal_lands or something similar when we can simply use boundary=aboriginal_lands. While boundary=protected_area seems to be working for mappers in Brazil, it doesn't appropriately describe the situation in North America or Australia, so I believe both tags are needed. FYI, it is likely that both tags will be rendered on openstreetmap-carto if this proposal is approved. --Jeisenbe (talk) 12:05, 29 November 2018 (UTC)
- I approve this proposal. While protected_area may seem like a better choice, we should strive for tags understandable without using some third-party classifications. --Zverik (talk) 12:28, 29 November 2018
- I approve this proposal. As someone mapping reserves, I regard this proposal as somewhat of a moot point for me - I'm already using the tag, as no vote is needed to map something. --Pnorman (talk) 13:47, 29 November 2018 (UTC)(UTC)
- Paul, while I respect and agree with "no vote is needed to map something," I also appreciate the sharpening of consensus and better dialog on this issue that the vote continues to offer us. One reason I voted No is because we now have two tagginig conventions to mean the same semantic. Voting allows us to better understand the community's reasoning behind "why one vs. the other." I believe that is productive dialog. Stevea (talk) 17:26, 29 November 2018 (UTC)
- I approve this proposal.would be great to get lands into OSM on a larger scale. --Emac (talk) 18:54, 29 November 2018 (UTC)
- I approve this proposal. --Shonondray (talk) 20:05, 30 November 2018 (UTC)
- I approve this proposal. --ClipArtJoel (talk) 11:31, 2 December 2018 (UTC)
- I approve this proposal. --Noznoc (talk) 13:54, 2 December 2018 (UTC)
- I oppose this proposal. In Canada and the US, at least, aboriginal lands are, very much, their own administrative region. They have their own police, their own government, and their own laws. I'm not against them having their own kind of tag, but it shouldn't overlap with boundary=administrative --Alan Trick (talk) 21:04, 2 December 2018 (UTC)
- I approve this proposal. These areas are certainly worth mapping. They don't fit into the admin_level hierarchy, and I've got no expectation that boundary=protected_area will ever be rendered, so a special "boundary=" tag seems reasonable to me. --Carnildo (talk) 21:31, 2 December 2018 (UTC)
- I approve this proposal. Should be represented. --vespax 21:44, 2 December 2018 (UTC)
- I approve this proposal. --Bdiscoe (talk) 23:13, 2 December 2018 (UTC)
- I approve this proposal. --RoxyNala (talk) 00:43, 3 December 2018 (UTC)
- I approve this proposal. --User:garylancelot (talk) 01:03 Monday, December 3, 2018 (UTC)
- I approve this proposal.
- The wiki edit logs show that this vote is from User:Baconcrisp, but they forgot to sign their name. --Alan (talk) 15:57, 3 December 2018 (UTC)
- I approve this proposal. --YetiSpaghetti I think this can be very beneficial if done carefully and respectfully. We would need to establish communication and possibly a relationship with these communities. Possibly give them the ability to utilize OSM to map it out. If outsiders do it, it could bring unwanted and dangerous attention to these communities and their historic sites that are not protected. (talk) 16:23, 3 December 2018 (UTC)
- I approve this proposal. --LSkalayo
- I approve this proposal. --_Poliwrath_ 16:23, December 3, 2018 (UTC)
- I approve this proposal. --Rmikke (talk) 17:52, 3 December 2018 (UTC)
- I approve this proposal. --Pizzagal (talk) 18:57, 3 December 2018 (UTC)
- I approve this proposal. --Erictheise (talk) 19:41, 3 December 2018 (UTC)
- I approve this proposal. --Vanessa KW Esto es importante y debe ser cambiado exactamente por lo descrito - eso si que quizas votar en este espacio no es lo mejor, porque puede ser que muchos que utilizan OSM no editan en el OSM wiki tanto, y tambien, bueno... como ya se ha dicho, todo esto esta en ingles, pero bien importante hablarlo
- I approve this proposal. --Tmacwhite (talk) 20:18, 3 December 2018 (UTC)
- I approve this proposal. creo que facilitará el mapeo de áreas de habitantes originarios en Argentina --Camello AR (talk) 01:54, 4 December 2018 (UTC)
- I approve this proposal. --MichNicole
- I approve this proposal. --Johna Rupire (talk) 13:52, 4 December 2018 (UTC) I'm see this proposal very important to osm. I would like to develop it more to include more related tags to improve osm data about indigenous peoples. In Perú, some of these territories, are called Reservas indígenas. Veo esta propuesta muy importante para osm. Me gustaría desarrollarla más para incluir más etiquetas relacionadas para mejorar los datos de osm sobre los pueblos indígenas. En el Perú, algunos de estos territorios, se denominan Reservas indígenas.
- I approve this proposal. Re-posting my GitHub comment here. I would like to speak on the idea of what the tags would be. I am a developer and member of the Muscogee (Creek) Nation so I have some insight into this. Tribal areas are mainly split into two areas in the US: reservations and boundaries. Reservations are areas which exist within a state, or across states, that are domains where mainly tribal members reside. Then there are tribal boundaries, which are areas where both Native and non-Native communities exist but that share jurisdiction between Native and non-Native governments. Examples of tribal boundaries can be found in OK with tribes such as the Muscogee (Creek) Nation (http://mcngis.com/images/stories/maps/MCN_JURISDICTION_2016.pdf), and Cherokee Nation (http://geodata.cherokee.org/CherokeeNation/) just to name a couple. Then things get more complex. For example, some tribes who were not set aside reservations will instead put land into trust for tribal members or for the government as a whole. An example of this would be the Thlopthlocco Tribal Town in Okemah, OK (http://tttown.org/about.html). In Florida, there is a band of traditional independent Seminoles who do not believe in land ownership and so have land that is put into trust for them by an outside organization (https://indianlaw.org/projects/past_projects/seminole). Ideas that I have for tags would be: `tribal_reservations`, `tribal_boundaries`, and `tribal_trust_lands`. These things can be very nuanced so I think tags which speak to each one would be ideal. It's very possible that there just might not be any information, or any one willing to share the information, in regards to tribal trust lands. So that one may prove to not be helpful. Now on to semantics. In the United States it's common for American Indians/Native Americans to just call one another Native. In South America, it's more common to hear Indigenous. And in Australia, it is more common to hear Aboriginal. This is mainly due to historical reasons and the same goes for the naming conventions above. For example, tribal_boundaries is used to refer to areas in OK, i.e. https://www.okhouse.gov/Documents/Districts/14-1101%20OK%20House%20and%20Tribal.pdf. The terms are certainly dated but it makes sense in terms of historical context. But I suppose you would like to find something that unifies them. If that is your goal then a more all encompassing term would be aboriginal with any term afterward referring to jurisdictional matters, i.e. boundary=aboriginal_lands, boundary=aboriginal_trust_lands, boundary=aboriginal_reservations, boundary=aboriginal_boundaries. That would be what would make the most sense to me. I hope this helps! --Adamrecvlohe (talk) 14:30, 4 December 2018 (UTC)
- Thanks for all this detail, Adamrecvlohe! I think it is important for OSM to be able to capture this level of detail, but I'm not sure if three related top-level tags is the way to do it. (Or even if it is the right way to do it, I suspect a proposal with these three related tags would not be approved by OSM's voters). For most data consumers (primarily map renderers, but also other users) people will end up treating these three categories similarly, likely showing them all with the same or similar style on a map. What do you think about using boundary=aboriginal_lands as a tag for all of these three types of area, and then distinguishing them with additional tags, such as aboriginal_lands=trust_lands, aboriginal_lands=reservation, aboriginal_lands=boundary (or maybe aboriginal_lands=shared_jurisdiction for that last one, for clarity). This solution makes things easier for data consumers, who can pay attention to those sub tags if the need they added detail, or can ignore them for a more general-purpose map. Using additional tags instead of three similar tags fits better with the way other features are described in the OSM data model. The specific subtags don't need to be decided now, we could discuss those after the current vote and make a new proposal for them after the generic boundary=aboriginal_lands tag has been approved. --Alan (talk) 21:40, 4 December 2018 (UTC)
- Thanks for the response, Alan! I am not a cartographer or even someone that uses the OSM data model on a daily basis so I defer to those with more expertise, like yourself, to vet my response. I am glad to see my proposal be used in another form as you proposed above, all of which I agree with, and will revisit this again when that specific proposal comes up. For the time being I think it is fair to approve the current proposal and address the nuance of tribal boundaries, reservations, and jurisdictions at a later time.
- Thanks for all this detail, Adamrecvlohe! I think it is important for OSM to be able to capture this level of detail, but I'm not sure if three related top-level tags is the way to do it. (Or even if it is the right way to do it, I suspect a proposal with these three related tags would not be approved by OSM's voters). For most data consumers (primarily map renderers, but also other users) people will end up treating these three categories similarly, likely showing them all with the same or similar style on a map. What do you think about using boundary=aboriginal_lands as a tag for all of these three types of area, and then distinguishing them with additional tags, such as aboriginal_lands=trust_lands, aboriginal_lands=reservation, aboriginal_lands=boundary (or maybe aboriginal_lands=shared_jurisdiction for that last one, for clarity). This solution makes things easier for data consumers, who can pay attention to those sub tags if the need they added detail, or can ignore them for a more general-purpose map. Using additional tags instead of three similar tags fits better with the way other features are described in the OSM data model. The specific subtags don't need to be decided now, we could discuss those after the current vote and make a new proposal for them after the generic boundary=aboriginal_lands tag has been approved. --Alan (talk) 21:40, 4 December 2018 (UTC)
- I approve this proposal. --Wille (talk) 17:46, 4 December 2018 (UTC)
- I oppose this proposal. aboriginal sounds as if it can (or shall) be used only for Aboriginies. Another wording would be more common like: boundary=indigenous_territory + indigenous=xxx --WalterSchloegl (talk) 21:56, 4 December 2018 (UTC)
- I approve this proposal. Seems good, a kind of official jurisdiction/authority of the territory that is not a city/state/country hierarchy. As in URN LEX juristiction concept (tags for legislative documents), boundaries of aboriginal lands are official jurisdictions. --Krauss (talk)
- I approve this proposal. The nuances of semantics and tagging can be discussed further, but I think that the proposal to add recognized (and therefore already mapped out) boundaries of indigenous / native / territories should be uncontroversial and a significant enhancement of OSM in relevant areas. It was actually surprising for me to learn that these were not on OSM already (apart from in Brazil where they currently are symbolized as protected areas). --Rudokemper (talk) 21:35, 5 December 2018 (UTC)
- I approve this proposal. I have added a few reserves in Canada. I originally added them as boundary=administrative+admin_level=8 but this didn't fit for reasons that have been explained above, so I started using boundary=aboriginal_lands instead. --DannyMcD (talk) 22:18, 7 December 2018 (UTC)
- I approve this proposal. It always bothered me that such a cartographically and societally significant feature would be relegated to an anonymous protect_class=* value, by contrast to boundary=national_park. The proposed tag will be more discoverable for both mappers and renderer developers. 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. – Minh Nguyễn 💬 19:49, 8 December 2018 (UTC)
- I approve this proposal. --Darrell (talk) 22:07, 13 December 2018 (UTC)