<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 2012-11-08 16:34, Sander Deryckere
wrote :<br>
</div>
<blockquote
cite="mid:CABUOUO8j13zeJdHx2y6Sy-XESOMC6dRAqv=9AWkFvhND5PjYJQ@mail.gmail.com"
type="cite"> Does everyone agree with this?<br>
</blockquote>
OK, I trust you, but read below<br>
<br>
<br>
<div class="moz-cite-prefix">On 2012-11-11 12:36, Ben Laenen wrote :<br>
</div>
<blockquote cite="mid:201211111236.05773.benlaenen@gmail.com"
type="cite"> On Sunday 11 November 2012 01:39:57 A.Pirard.Papou
wrote:
<blockquote type="cite"> On 2012-11-08 16:46, Ben Laenen wrote :
<blockquote type="cite"> On Thursday 08 November 2012 16:34:23
Sander Deryckere wrote:<br>
<blockquote type="cite"> Hi, I'm trying to organise the
boundaries a bit, there's not a lot of work on it, so it's
basically checking if there are no problems. There is a
problem I have found with Verviers though. If you look at
the relation (<a class="moz-txt-link-freetext"
href="http://www.openstreetmap.org/browse/relation/1407211">http://www.openstreetmap.org/browse/relation/1407211</a>)
you see that as subareas, the Arondissement of Verviers has
a French speaking part, and the German community. That
French speaking part get's a strange boundary type
(boundary=administrative_fraction), combined with an
admin_level=7 tag and the German speaking part has a
boundary=political tag. </blockquote>
German Community should be a boundary=administrative +
admin_level=5 Who keeps changing it to a boundary=political on
the wiki anyway?
<blockquote type="cite"> As administrative boundaries should
be nested nicely, I propose to delete the boundary 2436189,
and to use the municipalities of the Arrondissement of
Verviers as subareas. Just as with any other arrondissement.<br>
<br>
Does everyone agree with this? </blockquote>
Boundaries don't need to be nested. In our country it's
impossible to do so anyway. </blockquote>
What do you mean? That there should be a single relation called
Belgium or that all ways should be at level 8? </blockquote>
I mean that (for example) there's really no problem if two
enitities of the same admin_level overlap a certain area (so that
area belongs two both entities). E.g. Brussels belonging to both
Flemish and French Community. Or if an entity with admin_level=8
doesn't sit nicely inside an entity with admin_level=6. E.g.
German speaking community being part of the Liege province. Or
French community not spanning the entire Liege province. Ben</blockquote>
<br>
So, it's about correct nesting and overlapping...<br>
<br>
I think that programs doing checks could finger-point at overlapping
areas (within a relation) and that they could suddenly start
recursing to find overlapping subareas without warning.<br>
<br>
Belgian (boundary=) <b>administrative</b> areas are<br>
<ul>
<li>2+1 regions, <br>
</li>
<li>in which provinces, <br>
</li>
<li>in which arrondissements,</li>
<li>in which municipalities<br>
</li>
</ul>
According to the present map:<br>
<br>
<a href="http://www.openstreetmap.org/browse/relation/52411">Relation:
Belgium (52411)</a> <a
href="http://wiki.openstreetmap.org/wiki/Key:boundary?uselang=en"
title="The wiki description page for the boundary tag">boundary</a>
= <a
href="http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative?uselang=en"
title="The wiki description page for the boundary=administrative
tag">administrative</a><br>
Relation Flanders (53134) as subarea<br>
Relation Brussels-Capital Region (54094) as subarea<br>
Relation Wallonia (90348) as subarea<br>
<font color="#ff0000">Relation Flemish Community (53136) as subarea<br>
Relation French Community (78967) as subarea<br>
Relation German-speaking Community (2425209) as subarea<br>
</font><br>
As the territory is fully covered by the administrative entities I
mention above, there is no room for more "Belgium" administrative
areas than what is in black in this relation. If you add more, you
can't avoid overlapping.<br>
<a
href="http://www.belgium.be/fr/la_belgique/pouvoirs_publics/communautes/communaute_francaise/"><br>
According to the definition from the horse's mouth</a> : "La
Communauté française exerce ses compétences dans les provinces
wallonnes (à l'exception des communes germanophones) et à
Bruxelles."<br>
Is "la communauté française" a territory or a government?<br>
It's less than clear, but is anything clear in that field?<br>
<br>
I think we have these options:<br>
<ul>
<li>remove all XXX-C-s areas altogether (Like Google does ;-) )
(1)<br>
</li>
<li>consider that the XXX-C-s are not in the administrative tree
named Belgium but that they are in a different administrative
tree e.g. "Linguistic communities"</li>
<li>remove the XXX-C-s relations from any tree, make one per
language, allowing overlap and, if we are that kind, more
languages in a cultural style (2) <br>
</li>
</ul>
May language borderlines (ways) share region borderlines if they are
not nested?<br>
In principle not, because, according to the theoreticians, those
ways are supposed to be related to just one area (on each side) from
which they pick the boundary information.<br>
The ideal method to is to make multilinestrings (3) that nest
another border just like an arrondissement border would nest
municipality borders.<br>
But present software does not support way nesting (except <a
href="http://hiking.waymarkedtrails.org">hiking.waymarkedtrails.org</a>
I was told).<br>
When will we push that wagon to unleash many projects?<br>
<br>
Cheers, <br>
<br>
<table>
<tbody>
<tr>
<td valign="top">André.</td>
</tr>
</tbody>
</table>
<br>
(1) that avoids to send us back to mapping at each political change
<a href="http://www.youtube.com/watch?v=Ea_9yGV61Dg">like the Sphinx
merchants</a> :-)<br>
(2) A language tree commands to speak a given and single language.
Disjoint areas allow the people to speak different languages openly
like the "german-speaking" who are in fact very kind and calm people
speaking also French, or the very real Italian community of
Grivegnée who have their own church service in Italian (because they
don't understand Latin ;-))<br>
(3) I would have called them simply routes (super-routes).<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>