[OSM-talk-be] boundary names and my program

[A.Pirard.Papou]

On 2012-11-28 12:55, Jan-willem De Bleser wrote :
> On Wed, Nov 28, 2012 at 12:24 PM, Sander Deryckere <sanderd17 at gmail.com> wrote:
>> Why municipalities and not part-municipalities? When you enter a village,
>> you get signs as these:
>> http://1.standaardcdn.be/Assets/Images_Upload/2009/06/04/A7_BORDJE_IVH.MM.jpg.h170.jpg.280.jpg
>> So the part-municipality is in a bigger font than the municipality. I wonder
>> what's your reason to choose the municipality name if you really want the
>> lowest admin level.
Show me the village borders with a municipality name and I'll change them.
Send me the GPX traces of village borders and I'll map them.
But they won't be boundary=administrative, nor part of the tree I'm 
talking about, because there's no lower administrative entity than a 
municipality (except districts of Antwerp if what I read is correct and 
complete, and they should of course bear their names).
>> Although I'll never add those names myself (I think it's useless), I also
>> don't oppose adding the names. I only hope it happens consistently.
UK: Today, children, we will learn how to use OSM data: click on the 
border of our town, they call it a relation, and learn our neighbour 
towns: 58224617, 58217805, 58213970,58213967, 33002251, 172434383, 
33185408, 18459510, 32900355.

BE0: Today, ...Liège — Verviers,  Liège — Verviers, Trooz, Chaudfontaine 
, Esneux, Comblain-au-Pont,   Aywaille

BE1: Tomorrow, ...  Theux, Pepinster, Trooz, Chaudfontaine , Esneux, 
Comblain-au-Pont,   Aywaille

> This is precisely the problem, and is the same discussion we had about
> bicycle node networks - it *won't* happen consistently because it's a
> made-up name.
>
> Municipality, part-municipality, city, country... a border can border
> on multiple regions simultaneously, so why should one particular type
> get priority? Why "A - B" and not "B - A"? Why not prefix the name
> with the word "Municipality", so that people know that the two names
> are municipality names and not a different type of border?

I have presented this to tagging at osm, and I think I mentioned it on 
talk-be at osm:

The municipality (L8=level 8) border segments (ways between two 
municipalities) should be assembled with multilinestring to form 
arrondissement L7 border segments.
Then, the border of the arrondissement are now a much smaller number of 
L7 segments.
We may do the same at higher levels.
The L8 borders are tagged admin_level=8, name=municipalityA — municipalityB
The L7 borders are tagged admin_level=7, name=arrondissementA — 
arrondissementB
The L6 borders are tagged admin_level=6, name=provinceA — provinceB
and so on for upper levels or lower levels if they exist.

And then the meaningless saying "the highest admin_level wins" goes away 
by itself, especially when applied to names for which there is no reason 
to apply that rule.

THAT is consistent, coherent, compatible, congruous, harmonious, 
homogeneous, logical, solid, sound, straightforward, uniform,  you name it.

But... no answer that proposition.

Do you want me to apply that configuration on the borderline Liège — 
Verviers?
I have a test demo OSM update ready for that.

We will be able to evaluate the consequences.
I know one: JOSM does not support multilinestring and recursion. So, the 
configuration it makes is correct but continuity and loop test it makes 
will no longer exist for higher levels.  That's, a pity, but the most 
important test is the bottom-level one.  For he upper levels with only a 
few boundaries, good attention will suffice.  And the very simple 
program I wrote is quite capable of going down the tree and check for 
continuity and loop.

Any news about JOSM supporting recursion, e.g. as hiking routes use them?

We could otherwise not use multilinestring and use overlapping real ways 
but I find that ugly !!!

Shall I apply that test configuration?

Cheers,

André.









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20121129/f339f8b8/attachment.htm>