<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
<link href="chrome://translator/skin/floatingPanel.css"
type="text/css" rel="stylesheet">
<link href="chrome://translator/skin/floatingPanel.css"
type="text/css" rel="stylesheet">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
Thank you for your replies.<br>
Based on what you said, I projected a small rework of the Belgian
configuration.<br>
I'm discussing the options here and I'd appreciate your technical
approval before I suggest this option.<br>
I prefer to limit the discussion to what is needed to make the
practical decision. <br>
The proposed configuration is at the end of this message and should
raise no problem.<br>
The only point is a decision to make about admin_level.<br>
<br>
<administrativia><br>
On 2012-10-04 17:13, sylvain letuffe wrote :<br>
<blockquote cite="mid:1349363608559-5728971.post@n5.nabble.com"
type="cite">Q1e1 : I don't consider any naming invalid, and thus I
don't change what others have done<br>
Q1e2 : However I don't like using some strange caracters my
keyboard does'nt have like —<br>
</blockquote>
Strange you mention that. It happens that when I started helping my
compatriots with their boundaries, I arranged with a very nice
Belgian guy who had coordinated much over 4 years. Then I noticed
that municipality names I wrote were being changed without
discussing them and without warning. It turned out that those
changes were made by a Frenchman who was also forcing that character
upon us (1). </administrativia><br>
<br>
On 2012-10-04 08:41, Frederik Ramm wrote :
<blockquote cite="mid:506D2FAB.3000908@remote.org" type="cite">Hi, <br>
<br>
On 10/04/12 03:17, A.Pirard.Papou wrote: <br>
<blockquote cite="mid:506D2FAB.3000908@remote.org" type="cite">
<blockquote type="cite">1) While the A name= of the relation is
the name of the area, such as <br>
London or Wales, the possible B name has nothing to do with
the area. <br>
The B name can be that of a river, of a road, or the border
piece can be <br>
immaterial or chosen not to be represent the physical way. <br>
If the border line is immaterial, the name, if any, can be
chosen <br>
perfectly arbitrarily and serves only to identify the border
line at <br>
best when you look at configuration data or on the map. <br>
</blockquote>
<br>
In these cases I tend to omit the name tag altogether. After
all, the immaterial line doesn't really have a name; what you
are talking about is more of an "annotation", a "note", a
"description" or somesuch. <br>
</blockquote>
</blockquote>
In Belgium, we have chosen to use names.<br>
They are in fact very useful to read on the map and in listings
(those that are proposed to change first)<br>
- like this <a
href="http://www.openstreetmap.org/browse/relation/2413544">Sprimont
community border</a><br>
- or this <a
href="http://www.openstreetmap.org/browse/relation/1407191">Liège
arrondissement border</a><br>
<br>
An immaterial border segment between two municipalities is best
identified with the names of the municipalities.<br>
<br>
Unfortunately, the name Liège — Verviers (arrondissements) has been
used instead of community names<br>
- for some community border segments for which it is misleading<br>
- for long strings of arrondissement border segments for which it
makes no sense<br>
<br>
This was based on the principle that "the highest administrative
level wins" which is incorrect for names.<br>
<br>
The need for community names on community borders is best felt when
one draws them. It's quite easy to see which border one connects
another to (C1-C2 to C2-C3 to C3-C1). Using arrondissement names
instead is an error prone nightmare (C1-C2 to A4-A5 to C3-C1). When
the C-level is finished, grouping C-boundaries into A-boundary
relations with a zoomed out view is the easiest thing to do.<br>
<blockquote cite="mid:506D2FAB.3000908@remote.org" type="cite">
<blockquote type="cite">3) One can make routes of routes, that is,
relations of relations. <br>
Or, at least, routes of hiking routes. It seems that the
recursion <br>
support is an application matter. <br>
And we're ruled by chickens and eggs. <br>
Hiking software has implemented recursion, then hiking routes,
then more <br>
software. <br>
How extended is the recursion support of routes? <br>
Could it be used for boundaries? <br>
</blockquote>
<br>
You mean like this <br>
<br>
<a class="moz-txt-link-freetext"
href="http://www.openstreetmap.org/browse/relation/1111111">http://www.openstreetmap.org/browse/relation/1111111</a>
<br>
</blockquote>
When I suggested the route recursion solution (a too restrictive
concept), I was replied (by some Frenchman) that it's impossible.
And now I see that what you show me is EXACTLY what I had imagined
and what we need and that it's already used in Belgium!!! Only I
didn't know that I could use <a
href="http://wiki.openstreetmap.org/wiki/Key:type?uselang=fr"
title="La description de la balise <code>type</code>
sur le wiki">type</a> = multilinestring.<br>
<blockquote cite="mid:506D2FAB.3000908@remote.org" type="cite"> As
you can see, cascading relations are already in use for
boundaries, it's just that nobody is really sure how to do it
right ;) <br>
</blockquote>
Well, I don't see many different ways to do it, except variations in
tag details.<br>
The general structure is that each admin level border can optionally
assemble lower level and same level segments to build larger way
compounds which have the border attributes but are not
type=boundary.<br>
At some point, the loop closes and we have a type=boundary relation
that is defining a name and a level.<br>
<blockquote cite="mid:506D2FAB.3000908@remote.org" type="cite">
<blockquote type="cite">2) The admin_level itself is redundant in
ways. It is in fact contained <br>
in the boundary relations, and as it possibly has multiple
values if the <br>
border is for several area levels. <br>
</blockquote>
The consensus is to use the highest of all applicable admin
levels. You are right in saying that it is redundant (as is the
boundary=administrative tag, btw.) but it does make things easier
for those users who simply want to draw a line on their map - they
don't have to evaluate the, possibly broken, polygons for that. <br>
</blockquote>
If I put it "visually", what you say is that the admin_level is used
to choose the brush width used to paint the boundary without having
to fumble into the DB keys to find one or more relations containing
the way as a member and use their highest level.<br>
Now, what if, like in my proposed configuration, there are two or
more overlapping ways belonging to different levels?<br>
Shouldn't the lower level ways retain the true level and <b>the
highest one</b> follow the <b>highest level</b> rule?<br>
In other "visual" words, isn't painting according to those numbers
such that <b>the widest brush</b> will win. Painting all level
ways successively achieves the strongest rendering.<br>
Finally, if the Russian dolls process is made at each level, there
is no "winning level rule" needed any more.<br>
<br>
Well, practically, what I will propose is this:<br>
<br>
<a class="moz-txt-link-freetext"
href="http://www.papou.byethost9.com/maps/Belgian_boundaries/Li%C3%A8ge-Verviers.png">http://www.papou.byethost9.com/maps/Belgian_boundaries/Liège-Verviers.png</a><br>
<br>
<img alt="L-V"
src="http://www.papou.byethost9.com/maps/Belgian_boundaries/Li%C3%A8ge-Verviers.png"
moz-do-not-send="true" height="569" width="995"><br>
<br>
<br>
Is that correct?<br>
<br>
Thanks, Best regards,<br>
,<br>
<table>
<tbody>
<tr>
<td valign="top">André.</td>
</tr>
</tbody>
</table>
<br>
(1) I personally have no problem with that character —. I'm using a
system called Ubuntu that fully supports a keyboard device. I type
<compose> - - -. I have assigned <compose> to an unused
key with a sort of flying flag without a shaft. I'm told that,
after having used letters to write numbers up to the end of the
Middle Ages, some people changed to writing letters with numbers
requiring a computer keypad that doesn't exist on many laptops. And
that's even for writing characters common in their language like œ
(<compose> o e, here, of course).<br>
<div style="bottom: auto; left: 6px; right: auto; top: 260px;
display: none;" class="translator-theme-default"
id="translator-floating-panel"> </div>
<br>
<div style="bottom: auto; left: 442px; right: auto; top: 154px;
display: none;" class="translator-theme-default"
id="translator-floating-panel"> </div>
</body>
</html>