Belgium has not yet an admin level 10 ?

http://wiki.openstreetmap.org/wiki/Template:Admin_level_10
Could be useful to tag a gehucht/dorp/village/buurtschap/hamlet ?

“deelgemeenten” == dorp/villages → so no ?

Could be used for “wijken” (e.g. Wijk Bosstraat in Boom), but since we do not have good borders for that, they are not mapped.

– Edit: Nominatim seems to ignore Hamlets in Belgium now when addresses are given

Ik kan nog altijd niet goed “relaties” begrijpen, en daarom heb ik blijkbaar wat mis gedaan met de grens van Zottegem en Sint-Lievens-Houtem ; http://www.openstreetmap.org/relation/414562#map=14/50.9084/3.8572

Ik wilde nml. de grenzen van Oombergen ; https://nl.wikipedia.org/wiki/Oombergen op kaart brengen ,met dezelfde grens als op de oude Vandermaelen/Popp kaarten van Geopunt, doch, een deel van Oombergen is blijkbaar “ingelijfd” door Sint-Lievens-Houtem, en aldus ligt Oombergen in Zottegem EN in Sint-Lievens-Houtem;

Oombergen is blijkbaar een deelgemeente van Zottegem,en het gedeelte van Oombergen in Sint-Lievens-Houtem is GEEN deelgemeente hiervan. Cadgis van de FOD vermeld geen Oombergen op hun site ;
http://ccff02.minfin.fgov.be/cadgisweb/?local=nl_BE
Heb Oombergen dan als admin lvl 11 getagd, doch, als je maar tot lvl 9 kan gaan, is dit niet goed zekers?
Is er iemand die me een beetje wegwijs kan maken, of dit zelf oplossen ?

edit : Vandermaelen i.p.v. Vermaelen

EDIT : thanks to wambacher , who fixed it :wink:

De deelgemeentegrenzen in België vormen inderdaad een nogal complexe materie om correct te kunnen mappen, ook al omdat ze geen echte wettelijke basis meer hebben. Ondertussen ben ik al een tijdje bezig de deelgemeentes (heel geleidelijk aan) verder te mappen a.h.v. Popp, Vandermaelen etc., dus misschien heb je wat aan deze uitleg…

Voor alle duidelijkheid: dit is hoe ik het aanvoel en map, maar hopelijk kan dit toch wat opheldering brengen.

admin_level 8: gemeenten; oké in België
AL 9: deelgemeenten: gebieden die vóór de fusieoperaties van de jaren ‘60 en ‘70 zelfstandige gemeenten waren. Sommige gemeenten zijn in die periode wel meermaals gefuseerd en opgegaan in steeds grotere gehelen. Een logische aanname is m.i. dan om telkens (enkel) de kleinste eenheid (die bvb in 1950 een gemeente was) als AL9-relatie te mappen en niet de kortstondige tussenfases.
…en dan natuurlijk de netelige kwesties, open voor discussie:
AL 10: gebieden die ooit (bvb 19eE of voor WO I) wel zelfstandige gemeenten waren, maar al lang voor de grote fusies opgegaan zijn in andere gemeenten, of significante delen van gemeenten (met bvb een eigen dorpskern) die bij de grote fusies afgesplitst en elders toegevoegd zijn. Of ook significant grote (overkoepelende) wijken van een stad met een officiële grens.
AL 11: alle overige af te bakenen gehelen: afgesplitste gebieden zonder beduidende woonkern, kleinere officiële (wijk- of) buurtgrenzen…, eventueel de (nog nergens in OSM gemapte) statistische sectoren van het NIS?
AL 12: nog niet in gebruik in België (denk ik), eventueel ook mogelijk voor ‘buurten’ of statistische sectoren?
De echt minieme grenscorrecties (een enkel weiland, riviermeander…) zijn te verwaarlozen als aparte relation.

In o.m. Nederland en Duitsland, wordt al veelvuldig gemapt tot op admin_levels 10,11 en 12, dus dat lijkt me in België op zich ook geen probleem. Wat natuurlijk niet wil zeggen dat dat vele toepassingen die niveaus nog correct in rekening gaan brengen bij bvb adresbepaling.

Wat de “relations” betreft: in principe heeft een AL-relatie enkel subarea’s van de eerstvolgende hiërarchische trap als extra leden. De meeste gemeenterelaties zijn dus AL8 met enkel eventuele AL9’s als subarea. Al zijn er enkele die, om de bovenvermelde uitleg, daarnaast ook bijkomende AL10- (of 11-)relaties als rechtstreekse subarea kunnen hebben, als die op zich echt geen onderdeel zijn (geworden) van een AL9. Zo zie ik het toch, tenminste. Ik moet toegeven dat ik met zulke dingen ook vaak twijfel en zeker niet alles consequent op die manier heb gemapt…

Enkele voorbeelden: Scherpenheuvel-Zichem, Kapellen. Maar bij Tremelo heb ik dan blijkbaar weer wel de ‘correcte’ hiërarchie strikt opgevolgd: Tremelo (8) > Baal (9) > Balenberg (ex-deel Betekom) (10)

En dan specifiek de kwestie Oombergen, hoe ik het zie: het Zottegems deel van Oombergen kan je als AL9-relatie taggen (want hoofdmoot van de oude gemeente, maar AL10 kan ook?) en onderbrengen in AL8-relatie Zottegem. Het Houtemse deel wordt dan een AL10 of AL11-relatie die subarea wordt van AL8 Sint-Lievens-Houtem (of van AL9 S.L.H. als de hiërarchie toch strikt gevolgd moet worden)

De gehele oud-gemeente Oombergen ook apart mappen als admin_level=9 of 11 en/of als een “boundary=area”, zoals jij hebt gedaan, lijkt me in de huidige realiteit niet correct en mogelijk problematisch (voor adresbepaling etc.), want conflicterend met de huidige, reële gemeentegrenzen. Historisch gezien is het wel volledig correct natuurlijk, maar dat is eigenlijk nadrukkelijk niet het opzet van OSM…

Wat en hoe wambacher het nu juist gefixt heeft is me niet echt duidelijk?

Ik leg de kwestie voor de zekerheid ook even voor op de OSM-talk-be mailinglist.

Bedankt QuercE voor je grondige uitleg, ik heb nog een klein (ontbrekend) stukje “aangepast”, doch, die “grens-relaties” gaan wat “over mijn petje” , en laat ik best dan aan jou over :wink: .
Mijn “inmenging” in al die grenzen is enkel maar bedoeld om de exacte ligging ervan te mappen, want als je langsheen de verschillende gemeentegrenzen (die veelal maar “grofweg” geplaatst zijn, en soms ver van de exacte plaats) gaat, kom je nog vele fouten tegen i.v.m. straatnamen en huisnummers, en aldus zijn er mensen die blijkbaar een poging gewaagd hebben om huisnummers te taggen, en dan blijkbaar stoppen, omdat in de omgeving van gemeentegrenzen , het vaak zulk een kluwen is, dat zelfs geopunt/cadgis van FOD in “tegenspraak” liggen ; de ene zegt dit, en de andere dat.
Daarom pleit ik ; map eerst de exacte grensplaats, en dan kan men als beginner beter de gebouwen en straatnamen correct mappen in de omgeving van (gemeente)grenzen.
Ook wil ik nog kwijt, dat, wanneer je in JOSM, de grenzen koppelt aan een waterloop, geeft die altijd een “waarschuwing” (die niet nodig is volgens mijn opinie), wat veel beginners afschrikt denk ik.
Waterlopen zijn nu eenmaal DE grensbepalers in veel gevallen (just my 2 cents) :wink:

Natuurlijk is het exact mappen van de grens het voornaamste werk en bestaan er nog vele onnauwkeurigheden… Ik begrijp die frustratie en probeer ook altijd de bestaande grenzen nog te verfijnen wanneer ik er nieuwe map.

Wat die foutmelding betreft: het wordt algemeen meestal sterk afgeraden twee verschillende ways aan elkaar te ‘plakken’ en alle nodes te laten delen, omdat het o.m. latere bewerkingen vaak bemoeilijkt. Het is dan beter om ofwel een bestaande way (waterloop, straat…) bijkomend te taggen met bvb boundary=administrative en admin_level=X en die weg dan in een relatie te stoppen. Dat vergroot dan weer het aantal leden in een relatie alsook de kans op ‘gaten’. En in beide gevallen negeer je dan soms het feit dat de officiële (deel)gemeentegrens vaak nog altijd loopt volgens de 19de-eeuws ligging van de waterloop (bvb met meanders) of straatas, en nooit zijn aangepast aan de fysische realiteit.

Meestal map ik een grens dus als een volledig aparte way, uit 1 stuk zolang hij dezelfde gebieden scheidt. (Al is dat ook niet ideaal voor alle huidige toepassingen, die bvb een adres bepalen via een koppelng naar de dichtstbijzijnde highway die volledig binnen of op een grens moet liggen…)

Ter info, we hebben een project lopen om alle huisnummer te importeren aan de hand van AGIV CRAB, daarvoor hebben we de exacte grenzen niet echt nodig. Zie http://crab-import.osm.be/import.html, lees wel eerst de documentatie voor je er aan begint :slight_smile:

AGIV CRAB gasten komen hier op dit forum blijkbaar niet, want de fouten die ik hier eens melde, zijn er nog altijd bij hun :stuck_out_tongue: :

Ik had 2 foutmeldingen in januari gedaan, die werden vorige maand verwerkt. Dus nog even geduld :slight_smile:

@escada, hoever staat het met de import van Crab data? Ik merge nu nog die adresdata bij m’n osm data tbv de Garmin kaarten, Lambertus doet hetzelfde voor zijn kaarten, in hoeverre is dat nog zinvol?

Ik heb geen idee hoeveel data er reeds geimporteerd is. Als gewone gebruikers kunnen we dit enkel per postcode opvragen. Ik weet niet of sanderd17 dat op de een of andere manier kan controleren, maar ik betwijfel het. Ik vraag hem om zijn antwoord in dit draadje te plaatsen

Volgens Overpass zitten we momenteel aan 0,8 miljoen adressen in OSM. Dit op een totaal van ongeveer 3,3 miljoen adressen in Vlaanderen.

Dus ja, het is nog altijd interessant om de CRAB dataset zelf in de tools in te voegen. Let wel op, het aantal gemapte adressen verschilt enorm per regio. Vlaams-Brabant heeft bijvoorbeeld veel adressen, en in Oost-Vlaanderen is het dan weer heel mager.

Maar ondertussen hebben we ook toegang gekregen tot de GRB dataset (met o.a. gebouwcontouren), en deze dataset is ook aan CRAB gelinkt (voor de gebouwen die een adres hebben). Dus denken we om de GRB dataset op een iets geautomatiseerdere manier te importeren, en ondertussen ook de adressen mee te nemen die duidelijk zijn (de adressen die 1-op-1 overeenkomen met een gebouw). Dit zou (volgens mijn ruwe schatting) 90% van alle adressen in Vlaanderen moeten importeren, waarna we die overblijvende 10% manueel kunnen bijvoegen via de gebruikelijke CRAB procedure.

Ok, dank voor de update!