<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2014-07-19 08:00, Paul Johnson wrote
:<br>
</div>
<blockquote
cite="mid:CAMPM96o594cFKKAPjK1G=j3j22R-X0rc_V3SC0ML_eZ1RjWj3w@mail.gmail.com"
type="cite">
<div dir="ltr">I don't see how that's the case, the reason being
that the Supreme Court has clearly ruled that tribes are above
the state but semi-dependant on the fed, as far as the law is
concerned. Furthermore, the state may still intervene, but has
the option not to in situations where it would otherwise be
obligated, in tribal regions. This makes a state not dissimilar
to a county relative to the tribe, particularly in cases like
the Navajo and Iroquois, whose jurisdiction crosses state
boundaries.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sat, Jul 19, 2014 at 12:56 AM, Paul
Norman <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:penorman@mac.com" target="_blank">penorman@mac.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
On 2014-07-18 10:53 PM, Paul Johnson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I should add that I do not intend on changing state
boundaries, just mapping indian nations where I know the
boundaries to lie on the ground, as higher than state,
lower than the country, inside the US only, if that
wasn't clear on the admin level argument. It would
still be possible to render a map without such excluded
territory at a state level, since, in practice, there's
a LOT of overlap in responsibilities and jurisdiction.<br>
<br>
</blockquote>
</div>
What you're proposing badly breaks admin hierarchies - hence
the need to carve the bits out of the states if you wanted
to go that route.<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
Your solution would be to use another type of boundaries than
administrative, if not administered.<br>
But beware that the <a
href="http://wiki.openstreetmap.org/wiki/Boundary">Boundary key
specifications</a> look like changing every day.<br>
Lately, I was looking for other types than administrative and they
were removed.<br>
And now they're back.<br>
At the same time, some page stated that type=multipolygon is
deprecated for boundaries.<br>
I can't find that statement any more.<br>
<br>
This raised an issue with overpass API, for which, <a
href="http://wiki.openstreetmap.org/wiki/Overpass_API/Areas">to be
considered an "area", an element must</a><br>
<ul>
<li> have a tag <em>admin_level</em> and a tag <em>name</em>,
</li>
<li> have a tag <em>type</em> with value <em>multipolygon</em>
and a tag <em>name</em>,
</li>
<li> have a tag <em>postal_code</em>, or
</li>
<li> have a tag <em>addr:postcode</em>.
</li>
</ul>
Obviously, e.g. a national park has no admin_level and if it can't
be a multipolygon, it can't be an area.<br>
Same for some touristic region which I tagged for the renderer.<br>
But note that this spec has changed too, only for those who can read
overpass.<br>
<br>
I think that linguistic boundaries are badly missing.<br>
Based on the fundamental OSM rule that people do the same thing
different ways, I could use user_defined.<br>
But I really prefer OSM to be predictable.<br>
And there's is a contradictory boundary rule that what was correct
one day is decreed invalid the day after.<br>
So, I would appreciate someone to notify me that all the targets
have stopped moving ;-)<br>
<br>
<table>
<tbody>
<tr>
<td>André.</td>
</tr>
</tbody>
</table>
<br>
<br>
<br>
<br>
</body>
</html>