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

Thu Nov 29 14:58:13 UTC 2012

I feel with you, you are not the only person is disappointed in the working
of OSM in Belgium. In my opinion a few people have here own rules
(examples: don't use names, put this info in a note, use JOSM, etc) and
neglecking hundreds of driven volunteers.

In my opinion the problem is that there is no complete wiki and it seams
that some people can make their own rules.

Exemple : there was a majority for using "hiking" instead of "foot"
(Potlach preset hiking instead of foot). Its not on the wiki and all
"hiking's" were changed to "foot's". If we continue like that i am sure we
will lose a lot of people.

I hope you will still continue your work on OSM and hope that one day,
people will "listen" to arguments and that "specialists" will put their
energy in making the wiki (after voting) instead of never ending
discussions.

2012/11/29 A.Pirard.Papou <A.Pirard.Papou at gmail.com>

>  On 2012-11-29 09:23, Jan-willem De Bleser wrote :
>
>  On Thu, Nov 29, 2012 at 4:51 AM, A.Pirard.Papou <A.Pirard.Papou at gmail.com
> > wrote:
>
>> 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.
>>
>
> You're right, that does solve the "which layer?" problem. If you mentioned
> that earlier in the thread, I'm sorry, I must have missed it.
>
> The problem I have, however,  is that by using name=A-B, you're trying to
> give the boundaries a name when it really is the municipalities that have a
> name.
>
> To use your example above, what if the L8 boundaries are all members of
> multipolygon relations, each with the name of a municipality, the L7
> members of multipolygons named after arrondissements, and so on. If you
> have the border, it is a single api call to find which relations it is a
> member of, and then you can easily extract the name. This is pretty much
> what they suggest on the wiki (well, that or left: and right: tags). I
> assume your program could do that extra query without difficulty? Should be
> easy in Josm as it grabs any relation in the bounding box, but I'll have to
> take a look at Potlatch to see if it's possible there.
>
> Essentially, I don't want to have to "agree" on a name, I want to use the
> one that's already there.
>
> When I started to map Belgian boundaries, I looked for instructions on the
> Belgian pages and I found none.  So, I looked at what was being done, I saw
> that names were used on boundaries and I did the same.  And now I am *accused
> of **insisting* to put names on the borders when I found them that way.
>
> If I look at the result of the way it is done, I see nameA — nameB  name1
> name2 name3 name4 ... everywhere, sometimes being a municipality, sometimes
> being an arrondissement, sometimes being a province etc... without any clue
> for the map reader to know which is which.  And Namur or Liège can be three
> different types.
> The result of my view of the Boundaries is that, instead of seeing this on
> the border
> Liège — Namur  Havelange  Huy  Namur Dinant  Clavier Liège
> one would see
> Clavier — Havelange    Huy — Dinant (arr.)    Liège —Namur (prov.)
> beside the unavoidable pile of shit.
> To  this, I'm answered that the pile of shit is very well the way it is.
> That the nec plus ultra is a renderer taking the name (but not the
> admin_level!) off the municipality relation without the faintest notion of
> what are the names to be used for distinguishing admin levels.  And one
> will certainly not miss the occasion to roll out the refrain that I want to
> tag for the rendering.
>
> I, who would certainly be glad to map any community border like the
> Quartier des Marolles, am accused of not considering them as administrative
> borders because they can be used as postal addresses and of not mapping
> level 10 names everywhere.
>
> I just read a question of someone wanting to navigate down the boundary
> tree.  I do it, but the answer he received is that it is not possible.  It
> goes on..
>
>   Basically everything is "free-form" in OSM. There are conventions on
> tagging, but there is no guarantee people will stick to them.
>
> My own opinion is indeed that it's difficult and unreliable to obtain data
> from OSM.
> But, after reading for boundaries that one does it that way and the other
> another way and even in Belgium that they are nor doing it the way they say
> they must do it,  I have serious doubts about existing conventions too,
> conventions allowing to scan the tree here and not there.
>
> The net result of this is that I'm losing my time writing messages in hope
> of doing something right, that I hate doing things wrong and that, in
> consequence I'm leaving the boundary business.
>
> I will finish as perfectly as possible, as I did before, what I have
> promised to do.
>
> I started my boundary work by fixing borders that were 250 m away from
> their position and putting Banneux that was in arr. Verviers in arr. Liège.
>
> Don't forget to fix the other ugly, huge offsets in Belgian borders.
>
> Cheers,
>
>   André.
>
>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20121129/ea96b8da/attachment.htm>