Hi,
Thank you for your replies.
Based on what you said, I projected a small rework of the Belgian
configuration.
I'm discussing the options here and I'd appreciate your technical
approval before I suggest this option.
I prefer to limit the discussion to what is needed to make the practical
decision.
The proposed configuration is at the end of this message and should
raise no problem.
The only point is a decision to make about admin_level.
<administrativia>
On 2012-10-04 17:13, sylvain letuffe wrote :
Q1e1 : I don't consider any naming invalid, and thus I don't change
what others have done
Q1e2 : However I don't like using some strange caracters my keyboard
does'nt have like —
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>
On 2012-10-04 08:41, Frederik Ramm wrote :
Hi,
On 10/04/12 03:17, A.Pirard.Papou wrote:
1) While the A name= of the relation is the name of the area, such as
London or Wales, the possible B name has nothing to do with the area.
The B name can be that of a river, of a road, or the border piece
can be
immaterial or chosen not to be represent the physical way.
If the border line is immaterial, the name, if any, can be chosen
perfectly arbitrarily and serves only to identify the border line at
best when you look at configuration data or on the map.
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.
In Belgium, we have chosen to use names.
They are in fact very useful to read on the map and in listings (those
that are proposed to change first)
- like this Sprimont community border
<http://www.openstreetmap.org/browse/relation/2413544>
- or this Liège arrondissement border
<http://www.openstreetmap.org/browse/relation/1407191>
An immaterial border segment between two municipalities is best
identified with the names of the municipalities.
Unfortunately, the name Liège — Verviers (arrondissements) has been used
instead of community names
- for some community border segments for which it is misleading
- for long strings of arrondissement border segments for which it makes
no sense
This was based on the principle that "the highest administrative level
wins" which is incorrect for names.
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.
3) One can make routes of routes, that is, relations of relations.
Or, at least, routes of hiking routes. It seems that the recursion
support is an application matter.
And we're ruled by chickens and eggs.
Hiking software has implemented recursion, then hiking routes, then more
software.
How extended is the recursion support of routes?
Could it be used for boundaries?
You mean like this
http://www.openstreetmap.org/browse/relation/1111111
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 type
<http://wiki.openstreetmap.org/wiki/Key:type?uselang=fr> = multilinestring.
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 ;)
Well, I don't see many different ways to do it, except variations in tag
details.
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.
At some point, the loop closes and we have a type=boundary relation that
is defining a name and a level.
2) The admin_level itself is redundant in ways. It is in fact contained
in the boundary relations, and as it possibly has multiple values if the
border is for several area levels.
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.
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.
Now, what if, like in my proposed configuration, there are two or more
overlapping ways belonging to different levels?
Shouldn't the lower level ways retain the true level and *the highest
one* follow the *highest level* rule?
In other "visual" words, isn't painting according to those numbers such
that *the widest brush* will win. Painting all level ways successively
achieves the strongest rendering.
Finally, if the Russian dolls process is made at each level, there is no
"winning level rule" needed any more.
Well, practically, what I will propose is this:
http://www.papou.byethost9.com/maps/Belgian_boundaries/Liège-Verviers.png
L-V
Is that correct?
Thanks, Best regards,
,
André.
(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).
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
