Might some indigenous groups themselves distinguish between land that they own and land that they have sovereignty over? There have often been questions about how to distinguish between a reservation and, say, off-reservation trust land. It isn’t a perfect analogy by any means, but it reminds me of how some cities (as a corporate entity) own land well outside their borders, sometimes in other states, on behalf of their residents. In the case of off-reservation trust lands, I recall that it’s common for maps to denote them somehow, but not necessarily in the same manner as a reservation. I could be wrong about that though.
1 Like
I don’t disagree that administrative areas should be treated with the same respect, and that the thrust of this entire topic of conversation is “what’s a reasonable, consistent, easily entered and easily understood way of respecting the 'parallel sovereignty ’ of native peoples in the United States (and potentially elsewhere)?” That said, I don’t think I’m trivializing tribal government boundaries by saying “not all ‘aboriginal lands’ (such as we call them on OSM) are administrative”…
My problem is with using the “aboriginal” value just because the boundary is related to a First Nation. It would likely be appropriate for a purely cultural area. Like an area held sacred by multiple tribles. Maybe even lands shared by multiple authorities, First Nation or other governments. In any case, it should not be use when it represents a a clearly defined administrative boundary. Basically all administrative boundaries should carry the appropriate value irrespective of the government type.
One of the constraints we’re dealing with is an entrenched assumption that any boundary=administrative boundary needs to fit into a single, overly simplistic admin_level=* hierarchy. That leads to fraught questions too, like whether a federally recognized reservation’s boundary should be admin_level=2 or 3 or 4, whether it’s a good idea to have crisscrossing chapter boundaries and county boundaries with the same admin_level=*, and at the end of the day that still doesn’t solve the problem of how to indicate that the chapter belongs to the reservation rather than the state.
border_type=* can resolve some of the ambiguity for mappers looking closely at the data, but not for the constellation of existing data consumers that will go on treating native boundaries like their nonnative counterparts. However important the symbolism around the boundary=* tag we use, there’s a certain danger in erasing distinctions too. I think we’d have to coordinate with data consumers to avoid unintended consequences.
For what it’s worth, the Polish community has long mapped Catholic administrative territories, which are parallel to the secular hierarchy, as boundary=religious_administration with admin_level=*. So maybe these agency and chapter boundaries can have admin_level=* without issue. If we need to emphasize the administrative nature of these boundaries, what if we migrate to a new boundary=indigenous_administration tag? Yes, it still includes the word “indigenous”, but depending on how it’s documented, maybe the tag could be positioned as acknowledging rather than marginalizing indigenous groups?
3 Likes
I’m in favor of this, it’s definitely better than my current workaround of using subareas.
A federally recognized tribe is legally a domestic dependent nation, with territorial sovereignty independent of any state. So if we reuse admin_level=* for the external borders of a federally recognized Indian reservation but restart the numbering, it would be admin_level=2. This could surprise some data consumers who expect an admin_level=2 boundary to be at least a certain size. After all, the reservation can be bigger than many countries or as small as your backyard.
At this point, some might be thinking this is a great argument for eschewing admin_level=* in favor of something else like aboriginal_lands_level=2. However, there’s some value in preserving a relationship between a reservation boundary and the hierarchy of mainstream civil administrative boundaries. Federally recognized boundaries could be admin_level=4, similar to state boundaries. By contrast, a number of state-recognized Indian reservations do lie within the jurisdiction of a state. For example, the Shinnecock Reservation is subordinate to the State of New York. It’s currently tagged admin_level=8, as the state considers it to be equivalent to a village or hamlet.
Either way, I don’t think we need to worry about software developers who incorrectly assume admin_level=2 is an ISO-recognized country. Anyone making such an assumption is already misinterpreting a great number of boundary=census and boundary=religious_administration relations. Renderers and geocoders should consider the relation’s area, as OSM Americana does for labeling purposes, instead of using a numeric key as a proxy for area.
I am constantly impressed by the thoughtfulness Minh applies to topics such as these and the serious, appropriate research he offers us on this and many matters in OSM. Real-world examples of useful strategies, such as Americana’s labeling algorithms, vigorously support the sensible suggestions offered here.
I nod my head, I offer hearty encouragement to the continuing deployment of the various strategies and working-today solutions offered here, while I remain curious to see how others might approach
The real world maps (as in New York and the Shinnecock seemingly agreeing to tag admin_level=8) using particular methods for particular examples in OSM, yet this particular set of tags might only work in New York or other states where that state and a particular tribe / nation (DDN) agree to do so. Or, OSM may discover cases where it evolves to “be correct in OSM for that case” that using admin_level=4 because “both federally recognized” and “that’s how we do it in that state.” We can compare this multilateral approach with the many differences in hierarchy (state by state) that our US admin_level wiki attempts to explain, and further extend this to discovering case by case, state by state, what works across the US for federal tribes. But just like that large, complex and “slightly different everywhere, except where it seems there are broad similarities in some places” table conveys, we’d be doing this for federally recognized tribes. I think we can do this.
“Let a thousand flowers bloom,” (in OSM) as the saying goes. Though, I think the number of DDNs in the USA is 336. As long as there is no rancor between a state and the tribe (and OSM, which should keep to a crisp, small number of examples — at least at first), I think these can all evolve “as they might” given the guidelines we’re evolving here and now. Kudos to Minh again.
To clarify, I’m referring to real-world distinctions, not mere idiosyncratic tagging in OSM. The Shinnecock Reservation is an example of a reservation designated under state law but not federal law. The federal government doesn’t recognize the tribe for legal or judicial purposes, but consistent with the state, the Census Bureau does recognize the reservation as a subdivision of Suffolk County for statistical purposes. That’s what the admin_level=8 means. A state has a very different relationship to federally recognized tribe or their reservation.
1 Like
Yes, it still remains in our US admin_level wiki 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.
Yet, hammer out these distinctions is exactly what we’re attempting to do here.
Press on, everyone! This discussion seems to be bearing fruit.
The Census Bureau has published a diagram explaining the relationships between the various tribal and nontribal administrative areas. This is a heavily simplified diagram that elides, for instance, the three levels of the Navajo Nation and the potential for a state to designate a reservation at the county level or the county subdivision level. It also predates McGirt. Still, it speaks to the logic of assigning admin_level=* in relation to mainstream civil administrative boundaries.
In following annotated copy, I’ve highlighted in yellow the types of boundaries we’re currently tagging as boundary=aboriginal_lands without any formal tagging distinction. Based on what I know so far, I’m concerned that multiple highlighted items sit beside each other in the diagram and that there are highlighted items at multiple levels of the diagram. We’re just throwing everything that’s somehow indigenous into the same tag. (If this is not actually a problem, I’d welcome more information.)
In practical terms, the indistinct tagging elevates the subdivisions to reservations in their own right, making for a confusing map. In the following screenshots, it isn’t possible to tell where the Standing Rock reservation ends and the Cheyenne River reservation begins, or that the latter even exists, despite its size. Instead, it looks as if the reservations have been broken up – a problematic representation, given the history.
As boundary=aboriginal_lands apparently was never designed for anything but the top tier of “American Indian Areas (Federal)/Off-Reservation Trust Lands”, a conservative solution would be to split off boundary=indigenous_administration admin_level=* for federal reservation subdivisions and state-level reservations. In OSM Carto and OSM Americana, the subdivision boundaries would temporarily disappear. This would be unfortunate, but at least it would be possible to see the reservation boundaries again. Changes to these renderers would resurface the subdivision boundaries at a higher zoom level and with dashed lines.
A long-term split between boundary=aboriginal_lands and boundary=indigenous_administration would be awkward, so we need to decide whether and when to move the top-level reservation boundaries to boundary=indigenous_administration. Only a handful of data consumers recognize boundary=aboriginal_lands, so we might be able to migrate all the administrative boundaries over to a new tag simultaneously in coordination with the developers.
An alternative would be to combine admin_level=* with boundary=aboriginal_lands. But if the presence of admin_level=* is the only thing that distinguishes a reservation or subdivision boundary from something less structured, then we’ll probably keep finding examples of data consumers that mishandle these cases. It’d be as if we tag administrative boundaries as boundary=place, relying on admin_level=* to distinguish them from other verifiable boundaries.
3 Likes
I agree, it’s not the best system currently.
This seems like a good start, and I can make those changes in SD if everyone’s okay with that.
2 Likes
Here’s the Lake Traverse edits. Will do the others soon.
3 Likes
This came up at the time of previous discussion of how to tag reservations. There were people arguing that since a reservation can cross national boundaries it should be admin_level=1. This was not generally accepted and the conclusion was reservation organization was independent of administrative boundaries.
The fact that reservations can have a hierarchy within them doesn’t mean that it corresponds to the administrative hierarchy that we use admin_level for.
Modeling inter-governmental relations isn’t something normally done in OSM. We don’t do that for administrative boundaries, I don’t think we should attempt it for reservation boundaries.
Thanks for this apt reminder, Paul. Not only is THIS true, but the “administrative hierarchy that we use admin_levelfor” is itself (wholly independent of the concept of “indigenous”) a virtually nearly-endless set of nested specificities which are unique unto themselves. I say this repeatedly (as it bears repeating — as well as took me a while to fully understand, and others I remind of this also tell me they have a similar “a-ha!” moment). But it is true that “an admin_level=x which may be nearby or neighboring another may or may not have similarity or direct relationship with another admin_level=x.” Whether it does or doesn’t depends on whether it shares some level of “further up in the hierarchy,” but the further up you go, the less likely this is to be true. Safest is to assume it isn’t true, and only might be true when neighboring or “close in the up.”
Often, this fact is forgotten about admin_level, but it shouldn’t be, as it is perilous to do so. For example, in the USA,admin_level=4 often refers to each of the 50 states, yet there are also entities in the USA very sensibly taggedadmin_level=4which are not only wholly unlike states, as they ARE NOT states (territories, commonwealths, the District of Columbia…) but are not even like one another. Yet they are all 4s, if you can wrap your head around that. (You should).
This isn’t to say that havingadmin_levelhierarchies in OSM isn’t useful — we certainly have come to a consensus / agreement it is. But we absolutely must recognize its limitations, especially by not comparing a 6 here to a 6 there, for example, or even that a 2 in the world is precisely like another 2 in the world — these are false equivalencies. They are close, in some circumstances (but don’t count on it) and WITHIN a singular hierarchy (starting at 2 and drilling down to 10 or 11), there is a reasonable consistency that can go a long way to describe the concept of “administrative hierarchy.” But, don’t push your luck.
Throw in “indigenous” (history, peoples, the truly complex politics…) and you must recognize that these two concepts simply do not flatten into each other semantically in ways that “play nice.” We’d need something new, like some of the keys that Minh describes, but also recognizing the truism that blurring these (with admin_level) is done at our deep peril.
Once again, I think we can solve this. Many correct (well, at least better) ideas are being discussed, but this is a chewy one we’ve been (slowly) improving only over decades. This topic alone will soon enter its third year of discussion. I welcome more, though let’s keep going deeper. We’ve skimmed a lot of surface already.
How do you square this with the de facto use of admin_level=* on boundary=religious_administration to model a parallel ecclesiastical hierarchy? No renderer or geocoder that I’m aware of takes admin_level=* so literally that it ignores the value of boundary=*.
The approach that we’re taking in South Dakota is to tag the districts with admin_level=6, which implies that the surrounding federally recognized reservation would be admin_level=4. A state-recognized reservation would be either 6 or 8 depending on the state.
You’re describing the status quo. I’ve made the case that the status quo is inadequate for multiple reasons. Unless you have a viable alternative, I intend to draft a proposal for boundary=indigenous_administration admin_level=* based on what has been mapped in South Dakota so far. I haven’t decided whether to include the overall reservation boundary in that proposal, since that would impact a handful of data consumers.
1 Like
Update, all the subdivisions in SD should be taken care of. As I was going through, I noticed that Rosebud had a lot of small parcels outside of Todd County that are off-reservation trust land. Should we be mapping those?
It’s a parallel hierarchy that doesn’t try to make a relationship between it and the boundary=administrative hierarchy. This proposal does - it makes boundary=indigenous_administration admin_level=4 related to boundary=administrative admin_level=2
Looking at the example of France, a boundary=religious_administration admin_level=4 has no relationship to the boundary=administrative admin_level=4 regions.
So admin_level=6 is used for both subdistricts of a federally recognized reservation as well as a stand-alone state-recognized reservation? To me those seem unrelated.
You’ve misconstrued my argument. I never said we shouldn’t model sub-levels. We do that all the time - see regular administrative boundaries and religious administration boundaries. We don’t model inter-governmental relations in administrative boundaries. Taking the case of the overall reservation boundary, you’re saying that an admin_level=6 boundary=indigenous_administration is recognized by an admin_level=4 boundary=administrative or it is a subdivision of an admin_level=4 boundary=indigenous_administration. What’s what we don’t do right now with boundary=administrative.
I don’t think it’s possible to generalize completely. Off-reservation trust lands are technically property boundaries with ownership restrictions, but in practice many are governed like reservations or parts of reservations. Some native traditions don’t believe in land ownership, so instead of the tribe reserving the land for themselves, the federal or state government holds it in trust for them.
In the runup to the boundary=aboriginal_lands vote, a member of the Muscogee pushed for distinguishing between reservations and trust lands. We assured them that we’d address this point later, but we never did formally adopt a tagging scheme. For my part, I’ve been adding border_type=reservation/division/etc., so I’d use border_type=off-reservation_trust_land. But I’m unsure whether boundary=aboriginal_lands is a good choice for these boundaries either. The name of the value invites too much misunderstanding about the scope of indigenous territory mapping in OSM.
In the U.S., two boundaries with the same admin_level=* contained in the same boundary are often two of a kind, whereas two boundaries with the same admin_level=* contained in different boundaries aren’t necessarily related. For example, admin_level=7 may mean a town in one state or a township in another. For better or worse, border_type=* is how we distinguish two boundaries that have the same topological rank but different titles. The distinction rises to the level of boundary=* when other secondary keys (such as admin_level=*) need to be interpreted differently.
OK, I see what you’re saying now. Starting the federally recognized reservations at admin_level=4 would result in a tree similar to the one the Census Bureau published:
But you make a good point that federal versus state recognition would be a matter of intergovernmental relations, and in reality a federally recognized tribe has a complex relationship to both the federal and state governments. So the alternative would be to keep the hierarchies completely separate.
The South Dakota reservations are already modeled more or less like this, with the exception that admin_level=6 would become admin_level=4, implying that the reservation boundaries would be admin_level=2 when we get to the point of retagging those.
In the past, some federally recognized tribes have spoken out against the practice of state recognition. I don’t know if this is still a contentious issue or not. If necessary, the titular difference between a federal reservation and a state reservation could correspond to border_type=reservation and border_type=state_reservation, respectively. Or we could model it as a geopolitical dispute, e.g., disputed_by=US recognized_by=US-NY.
Most state reservations are quite small, so a renderer at a given zoom level would filter reservations by area regardless of federal recognition. No geocoder currently considers indigenous boundaries when qualifying locations, but the starting admin_level=* doesn’t really matter as long as the boundaries are consistent relative to each other.
For example, Chinle Agency got stuffed into the mainstream civil hierarchy as boundary=administrative admin_level=7, so the website’s Nominatim-based search results label Pinon with a confusing, incomplete mix of mainstream and tribal boundaries:
Village Pinon, Chinle Agency, Navajo County, Arizona, United States
But if we retag Chinle Agency as boundary=indigenous_administration admin_level=4 border_type=agency, the search result could label both hierarchies simultaneously in one of the following forms:
Village Pinon, Navajo County, Arizona, United States (Chinle Agency, Navajo Nation)
Village Pinon, Chinle Agency, Navajo Nation (Navajo County, Arizona, United States)
I don’t know that Nominatim is actually prepared to return parallel hierarchies in a search result. It might be something that requires backend architectural work. But I think this concept brings some clarity to the choice of boundary=*_administration over boundary=aboriginal_lands, which is so easily confused with a land acknowledgment.
Minh, Paul, Miles…really everybody who contributes to these discussions: I bow in deep obeisance to all of you. This is difficult work, yet we chug on through it. Excellent!
Okay, I’ll break those off with boundary=indigenous_administration as the main tag when I get to them and leave boundary=aboriginal_lands for the main reservation areas.