[Tagging] Naming boundary ways

A.Pirard.Papou A.Pirard.Papou at gmail.com
Wed Oct 10 19:43:51 BST 2012


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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20121010/a9ad9494/attachment.html>


More information about the Tagging mailing list