On 2012-11-16 23:33, A.Pirard.Papou wrote : > On 2012-11-11 12:36, Ben Laenen wrote : >> On Sunday 11 November 2012 01:39:57 A.Pirard.Papou wrote: >>> On 2012-11-08 16:46, Ben Laenen wrote : >>>> On Thursday 08 November 2012 16:34:23 Sander Deryckere wrote: >>>>> Hi, I'm trying to organise the boundaries a bit, there's not a lot >>>>> of work on it, so it's basically checking if there are no >>>>> problems. There is a problem I have found with Verviers though. If >>>>> you look at the relation >>>>> (http://www.openstreetmap.org/browse/relation/1407211) you see >>>>> that as subareas, the Arondissement of Verviers has a French >>>>> speaking part, and the German community. That French speaking part >>>>> get's a strange boundary type (boundary=administrative_fraction), >>>>> combined with an admin_level=7 tag and the German speaking part >>>>> has a boundary=political tag. >>>> German Community should be a boundary=administrative + >>>> admin_level=5 Who keeps changing it to a boundary=political on the >>>> wiki anyway? >>>>> As administrative boundaries should be nested nicely, I propose to >>>>> delete the boundary 2436189, and to use the municipalities of the >>>>> Arrondissement of Verviers as subareas. Just as with any other >>>>> arrondissement. >>>>> >>>>> Does everyone agree with this? >>>> Boundaries don't need to be nested. In our country it's impossible >>>> to do so anyway. >>> What do you mean? That there should be a single relation called >>> Belgium or that all ways should be at level 8? >> I mean that (for example) there's really no problem if two enitities >> of the same admin_level overlap a certain area (so that area belongs >> two both entities). E.g. Brussels belonging to both Flemish and >> French Community. Or if an entity with admin_level=8 doesn't sit >> nicely inside an entity with admin_level=6. E.g. German speaking >> community being part of the Liege province. Or French community not >> spanning the entire Liege province. Ben > > So, it's about correct nesting and overlapping... > > I think that programs doing checks could finger-point at overlapping > areas (within a relation) and that they could suddenly start recursing > to find overlapping subareas without warning. [...]
Regarding my concern to avoid overlaps... Exactly what I said did not happen (yet?) but if you query Nominatim, you will get: City Brussels, Brussels-Capital, French Community, Brussels-Capital Region, 1000, Belgium <http://www.openstreetmap.org/?minlon=4.35168409347534&minlat=50.8465385437012&maxlon=4.3516845703125&maxlat=50.8465423583984> Nominatim calls Brussels French-speaking because it does not support overlapping areas. Do Busselairs live in two "communities" or in one that is bilingual? (and that "Village Boundary Brussels, ... <http://www.openstreetmap.org/?minlon=4.33549880981445&minlat=50.7964057922363&maxlon=4.40201187133789&maxlat=50.8904113769531>" is funny but that's another story) > ... Community should be a boundary=administrative + admin_level=5 > Who keeps changing it to a boundary=political on the wiki anyway? The wiki is as it "should"... it states that 2 Linguistic Communities (Gemeenschappen / Communautés / Gemeinschaften) <http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries#Linguistic_Communities_.28Gemeenschappen_.2F_Communaut.C3.A9s_.2F_Gemeinschaften.29> are boundary <http://wiki.openstreetmap.org/wiki/Key:boundary>=administrative <http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative> admin_level <http://wiki.openstreetmap.org/wiki/Key:admin_level>=5 But the map is not... I see for example that Flemish Community <http://www.openstreetmap.org/browse/relation/53136> is now a boundary <http://wiki.openstreetmap.org/wiki/Key:boundary?uselang=en>=political <http://wiki.openstreetmap.org/wiki/Tag:boundary=political?uselang=en> relation but that its ways (like 125772618 <http://www.openstreetmap.org/browse/way/125772618>) are boundary <http://wiki.openstreetmap.org/wiki/Key:boundary?uselang=en>=administrative <http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative?uselang=en>. It used to be as it "should" but someone changed it, seemingly undiscussed. It happened in changeset 14165030 <http://api.openstreetmap.fr/browse/changeset/14165030> on 12/5/12 (w/o date format!). And this recalls me a message: Date: Tue, 01 Oct 2013 23:57:54 +0200 From: Ben Laenen <benlae...@gmail.com> To: talk-be@openstreetmap.org > Great, now change it back the way it was. You don't do that without > discussion. > > Greetings Ben I am surprised that those who do not start a discussion are not spoken of, that those who start a discussion are accused of not doing it and that their discussion is not continued. > Boundaries don't need to be nested. In our country it's impossible to > do so anyway. They need to. You see what can happen if they overlap. My fears are right. And, AFAIKS, it's quite "possible": making the linguistic boundaries political as they stand solves the problem. As the administrative and political boundaries are different types, they don't overlap. (I was saying that the overlap started in relation Belgium) The only remaining problem is Brussels, if I don't miss anything. But how does Nominatim nest areas? Try to make sense of this ;-) Village Yosemite Village, Mariposa County, California, United States of America <http://www.openstreetmap.org/?minlon=-119.586891174316&minlat=37.7481803894043&maxlon=-119.586883544922&maxlat=37.7481842041016> Attraction Yosemite, Village Drive, Yosemite National Park, Yosemite Village, Mariposa, California, United States of America <http://www.openstreetmap.org/?minlon=-119.589340209961&minlat=37.748851776123&maxlon=-119.589332580566&maxlat=37.7488555908203> National Park Yosemite National Park, Mt. Hoffmann Trail, Yosemite National Park, Mariposa County, California, United States of America <http://www.openstreetmap.org/?minlon=-119.886344909668&minlat=37.4948387145996&maxlon=-119.199501037598&maxlat=38.186351776123> Yosemite National Park <http://www.openstreetmap.org/?minlon=-119.886344909668&minlat=37.4948387145996&maxlon=-119.199501037598&maxlat=38.186351776123> is boundary <http://wiki.openstreetmap.org/wiki/Key:boundary?uselang=en>=national_park <http://wiki.openstreetmap.org/wiki/Tag:boundary=national%20park?uselang=en> but is delimited by boundary=administrative ways etc... Cheers, André.
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
