<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi all,<br>
<br>
Please all, take a very attentive look at this.<br>
Please note the subject change: unnecessary.<br>
Please note the disambiguation boundary vs borderline.<br>
<br>
The problem with admin_level tags is that numbers need to exist to
<b>be
</b><b> able</b> to nest boundaries and hence that only
administrative boundaries are nestable.<br>
That problem does not exist with subarea relation roles which:<br>
<ul>
<li>can do the nesting without any sort of level number,
including none, and with any boundary type</li>
<li>can even nest one boundary type such as administrative
inside another such as political to avoid duplicating
identical trees of two types</li>
<li>hence make never-ending discussions unnecessary about which
numbers to use or how to insert a level between 6 and 7;
levels can and should be replaced by names such as "province"
and "district" with the result that a map can tell (name)
"province Liège" from "arrondissement Liège" (and "city
Liège")<br>
</li>
<li>are much more explicit than levels (plain list of provinces
instead of having to discover them by level)</li>
<li>can easily cross-check subareas with existing levels, and
would probably easily find level mistakes</li>
<li>similarly, could easily be <b>generated</b> from existing
levels<br>
</li>
<li>are much more easier to design and tag, I can tell<br>
</li>
<li>to answer a frequent duplication criticism:<br>
</li>
<ul>
<li>they certainly duplicate less than a myriad of cases like
<a href="https://www.openstreetmap.org/relation/52411">boundary
Belgium</a> and <a
href="https://www.openstreetmap.org/node/1684793666">place
Belgium</a> (that should be identical and are certainly
different), and other uncriticized duplications<br>
</li>
<li>it's not really duplication if the form is so different</li>
<li>and if both subareas and levels existed everywhere and we
got accustomed to subareas, I wonder which we would find
superfluous</li>
</ul>
</ul>
Notorious cases of subareas are<br>
<ul>
<li>"ceremonial" <a
href="https://www.openstreetmap.org/relation/52411">Berkshire</a>
that is not administrative, has no level and yet contains
administrative "councils"<br>
Berkshire itself, however, is not a subarea of a higher level
but it could<br>
</li>
<ul>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/113682"><bdi>Bracknell
Forest</bdi> (<bdi>113682</bdi>)</a> as subarea</li>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/115074"><bdi>Reading</bdi>
(<bdi>115074</bdi>)</a> as subarea</li>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/117097"><bdi>Slough</bdi>
(<bdi>117097</bdi>)</a> as subarea</li>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/116938"><bdi>West
Berkshire</bdi> (<bdi>116938</bdi>)</a> as subarea</li>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/111014"><bdi>Windsor
and Maidenhead</bdi> (<bdi>111014</bdi>)</a> as subarea</li>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/114311"><bdi>Wokingham</bdi>
(<bdi>114311</bdi>)</a> as subarea</li>
</ul>
<li><a href="https://www.openstreetmap.org/relation/52411">Belgium</a>
is the top of two boundary subtrees that share much of the
same lower subtrees:</li>
<ul>
<li>administrative</li>
<ul>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/53134"><bdi>Flanders</bdi>
(<bdi>53134</bdi>)</a> as subarea</li>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/54094"><bdi>Brussels-Capital</bdi>
(<bdi>54094</bdi>)</a> as subarea</li>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/90348"><bdi>Wallonia</bdi>
(<bdi>90348</bdi>)</a> as subarea</li>
</ul>
<li>political, which is linguistic administration<br>
</li>
<ul>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/53136"><bdi>Flemish
Community</bdi> (<bdi>53136</bdi>)</a> as subarea</li>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/78967"><bdi>French
Community</bdi> (<bdi>78967</bdi>)</a> as subarea</li>
<li class="relation">Relation <a title=""
href="https://www.openstreetmap.org/relation/2425209"><bdi>German-speaking
Community</bdi> (<bdi>2425209</bdi>)</a> as subarea</li>
</ul>
</ul>
<li class="relation">multilingual Switzerland would be another
good candidate<br>
</li>
</ul>
There should be a "language" type of boundaries and the second
Belgian subtree could be of that type.<br>
For fast and easy navigation, there should be a "parent" role for
a boundary relation to indicate the tree(s) under which it
belongs. And also some manner for the borderline ways to indicate
all the boundaries that they belong to, at least the top one.<br>
<br>
I'm not going to go into that, but, in theory, subareas make the
"outer way" roles unnecessary for higher boundaries of the tree. I
think it's always true that the borderline of a level is the sum
of the borderline ways of all the levels below it from which the
ways that appear twice are eliminated.<br>
The process, however, is recursive, long for top levels like a
country. It needs accessing all its borderline pieces, both
external and internal. While that sometimes stated remark is true,
it's better to use a utility that does that process at tagging
time.<br>
That process is also at the core of a boundary consistency check,
such as being closed etc.<br>
<br>
In a first phase, the subareas could be generated by an automatic
process.<br>
In a second phase the level based nesting could be automatically
derived from the subareas.<br>
<br>
Thanks for your attention,<br>
<br>
Cheers
<br>
<br>
<table>
<tbody>
<tr>
<td>André.</td>
</tr>
</tbody>
</table>
<br>
On 2018-03-10 01:51, Matthijs Melissen wrote:<br>
</div>
<blockquote
cite="mid:CAD940Mr7VJCx07i=Ln=Z0b4tFnxTAtTEvj_kMA_jCBbbR0q+sQ@mail.gmail.com"
type="cite">
<pre wrap="">Hi all,
OpenStreetMap Carto, the default stylesheet on openstreetmap.org, is
considering to change the mechanism for rendering admin boundaries.
The proposed rendering of admin borders will be based on admin
boundary ways rather than polygons. This has a number of advantages -
for example, it will make it possible to style maritime boundaries
differently.
The admin boundary ways are already in the database. However, in some
cases they are missing an admin_level tag. When the proposed style
change will be deployed, boundary=administrative ways without
admin_level tag will no longer be rendered. I would therefore suggest
to make sure admin_level tags are present on all
boundary=administrative ways.
A map showing admin boundary ways without admin_level tag (displayed
in gray) can be found here:
<a class="moz-txt-link-freetext" href="http://product.itoworld.com/map/2?lon=20.00736&lat=51.92203&zoom=6">http://product.itoworld.com/map/2?lon=20.00736&lat=51.92203&zoom=6</a>
As can be seen, most countries already do have admin_level on ways.
However, in for example Poland, Iran and Australia, this data seems to
be missing.
-- Matthijs
_______________________________________________
Tagging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
<br>
</body>
</html>