Grenzen in Nederland

Ik zou andere mappers die met de CBS-data aan de gang willen gaan ook willen stimuleren om dezelfde aanpak te hanteren: gebruik de CBS-grenzen als basis, maar vel je eigen oordeel. Het gaat dus met name nog wel eens mis bij naamgeving en kleine buurten bij de CBS-data.

Je ziet het bij sites zoals Funda ook: huizen in wijk ‘X’ (CBS-naam) terwijl geen enkele daadwerkelijke bewoner van die wijk de wijk zo noemt.

De Händelstraat in Leeuwarden ligt bijvoorbeeld in de Componistenbuurt, en veel Leeuwarders noemen die buurt ook wel de Muziekwijk, beide namen staan erin op OSM — het CBS (en dus ook Funda en wie weet wat meer) noemt hem doodleuk Sonnenborgh (een naam die de gemeente zelf ook niet hanteert), maar je gaat hier geen Leeuwarder vinden die weet waar dat ligt, behalve mensen die nog weten dat dat een verzorgingshuis was en dat het een historische naam is van (volgens mij) een boerderij of buitenplaats, en de naam van een plaatselijke kaatsclub.

Done: https://www.openstreetmap.org/changeset/67018832

De admin_level tags zijn verwijderd, zie: https://www.openstreetmap.org/changeset/66974128

En daarvan bijvoorbeeld: https://www.openstreetmap.org/way/625930112/history

Ook de geometrie van de CBS data laat te wensen over, en komt vaak niet overeen met woonplaats en gemeentegrenzen.

Daarom zou ik de wijken en buurten liever geen boundary ways laten delen met de officiële administratieve grenzen zodat de geometrieën volledig gescheiden zijn. Dit is momenteel niet het geval in Leeuwarden en Amersfoort.

De geometrieën sluiten in werkelijkheid ook exact op elkaar aan. Een wijk aan de rand van een gemeente loopt doorgaans tot aan de gemeentegrens en volgt die daar exact.

Ik gebruik in Leeuwarden alleen de binnengrenzen van het CBS, en soms zelf ingetekend waar het CBS niet volstaat of achterloopt. De buitengrenzen (stad en gemeente) hergebruik ik uiteraard; dat is voor grenzen logisch, want zo wordt dat ook bij plaats-, gemeente- en landsgrenzen gedaan. Anders krijg je overlappende ways die exact op dezelfde plek liggen, en exact hetzelfde segment ‘grens’ markeren.

Bijvoorbeeld deze wijk, die als onderdeel van zijn grens dit stuk gemeentegrens gebruikt.

En hier een voorbeeld waarbij een gemeentegrens een landsgrens hergebruikt.

Daarbij volg ik de gangbare OSM-wijze waarop de hoogste hiërarchie leidend is voor de tagging van het stuk grens. In bovenstaand geval is dat de gemeentegrens.

Uiteraard is het niet de bedoeling dat de CBS-grenzen bestaande gemeente- en plaatsgrenzen vervangen. Die worden immers prima bijgehouden op OSM.

Niet alle metropoolregio’s zijn verdwenen. In ieder geval bestaan de Metropoolregio Rotterdam-Den Haag (https://mrdh.nl/) en de Metropoolregio Eindhoven (https://metropoolregioeindhoven.nl/) nog, alhoewel met minder bevoegdheden dan ze als plusregio hadden. Ik zie wel dat ook de nog bestaande metropoolregio’s uit OSM zijn verwijderd.

Nog even een vraagje, Nijmegen is formeel door de gemeente ingedeeld in stadsdelen, wijken en buurten, zoals ook opgenomen in de BAG. Als we voor deze indeling niet meer de administratieve grenzen kunnen gebruiken, hoe moet deze indeling dan wel gemapt worden? Ik neem aan dat we daar dan respectievelijk place=suburb, place=quarter en place=neigbourhood voor gaan gebruiken.
Als dat zo is dan vraag ik me wel af waarom sebastic alle grenzen heeft verwijderd en niet omgetagged heeft naar deze nieuwe indeling.

Dat weet ik niet. Ik heb in Venlo de wijken die ik belangrijk vind als node ingetekend met
place=quarter
name=Xxxx

Je kunt Sebastic met een persoonlijk bericht vragen wat er gebeurd is?
Nijmegen heeft zo te zien (taggen voor de renderaar, fout he :laughing: ) geen wijken en ziet er een beetje kaal uit :wink:

Nou gewoon zoals jij dat wil want jij bent een van de plaatselijke mappers.

Er is m.i. geen toegevoegde waarde voor grenzen die niet voor adressering of bestuur gebruikt worden.

De wijk/buurt grenzen die in OSM stonden waren veelal eenmalig geimporteerd en sindsdien nooit meer geupdate, en verliezen zodoende ook aan waarde.

Als men grenzen onder woonplaatsniveau in OSM wilt hebben voor hun stad, moet dit net als de BAG import actief onderhouden worden.

Dat is een persoonlijke mening. De gemeente stelt deze grenzen echter niet voor niets vast. Zo worden onder andere inrichting en onderhoud van de openbare ruimte, ontwikkelingsthema’s, stadsgetallen en wijkbeschrijvingen gebaseerd op deze grenzen.

Is dat niet het hele principe van OSM? Natuurlijk heeft een kaart in een veranderende omgeving actief onderhoud nodig, maar dat is toch waar wij met z’n allen continue mee bezig zijn?
Je geeft aan dat de grenzen veelal na de import niet meer geupdate waren. Ik vraag me af waarop dat gebaseerd is. Dit soort grenzen veranderen gelukkig niet regelmatig. Voor Nijmegen kan ik garanderen dat ze up-to-date waren voordat ze verwijderd werden.

In het geval van de wijk/buurt grenzen is dat niet waar de lokale community mee bezig is.

Historie van de objecten, en vergelijking met recente CBS data.

Grenzen veranderen vaker dan je zou denken. Nieuwbouw en wegomleggingen zijn hier vaak de oorzaak van.

De wijk/buurt grenzen zullen actief gemonitored moeten worden om dit soort wijzigingen te detecteren en gebruiken als trigger voor een update in OSM.

Mooi dat dit automatisch bijgehouden kan worden.
En fijn dat je dat doet sebastic.

Wat ik nu wel zie in Amsterdam/Diemen/Duivendrecht is dat er wel wijk- en buurtgrenzen worden getrokken.
Deze maken dan gebruik van landuse=residential, name=… (en evt. place=neighbourhood).

Die grenzen lopen vervolgens door allerlei andere gebieden heen (b.v. landuse=grass/comercial).
Wat weer aanleiding is voor warnings in josm (Overlapping Areas).

Persoonlijk vind ik dat er geen warnings en errors mogen zijn. Ben ook bezig om die op te lossen.
Maar met al die overlappende landuse grenzen is het wel lastig.

Wat foutmeldingen betreft, zou boundary=administrative beter uitkomen.
Daar wordt, volgens mij, niet geklaagd over overlappende grenzen. In ieder geval niet bij overlap boundary/landuse.

Wat is het idee om hiermee om te gaan?

PS.
De aanleiding.
Verschillende foutmeldingen over overlappende gebieden:
https://www.openstreetmap.org/way/45463132

Voor gebieden in Amsterdam, in dit geval Frankendael: https://gebiedinbeeld.amsterdam.nl/#/dashboard?gebied=DX15&wijk=M55&buurt&thema=Gebied%20in%20het%20kort

Dit komt dus sowieso niet goed overeen met osm.
Met name dan het stukje bij de Amstel (Van der Kunbuurt).

Maar ik weet vooralsnog niet hoe dit te automatiseren.

PPS.
Dit schema is wel mooi orthogonaal (een provincie in het ene land ligt niet ook in een ander).
Maar het heeft wat inflexibels:

  • levels zijn landspecifiek maar globaal gefixeerd;
  • maximum van 11; in principe: hoezo? Ik snap dat de veel lagere levels niet bij te houden zijn. Hoewel dat mss voor grote gemeentes, zoals Amsterdam, anders is.
    Wellicht een andere discussie…

landuse=* is voor de geometrie van CBS wijken & buurten niet juist, boundary=administrative is dat ook niet.

Zie het voorbeeld van Leeuwarden in de OP voor een acceptabel alternatief.

Daarnaast zorgt het taggen van de naam op de residentials dat de wijkgrenzen totaal niet kloppen. De naam wordt getagd op het woongedeelte van Frankendael, waardoor het lijkt alsof de andere delen, zoals het park en verschillende grasvelden aan de rand, niet tot Frankendael behoren.

Samenvattend:

boundary=administrative + admin_level=* (admin_level <= 11)
wordt alleen gebruikt voor addressering; automatisch import

boundary=statistical + border_type=district/neighborhood
voor een CBS wijk/buurt

boundary=place + place=quarter/place=neighbourhood
wordt gebruikt in Leeuwarden

Ik heb daar een aantal dingen bijgezocht:

  • boundary=statistical[list=*]

  • heeft geen wiki

  • is niet vaak gebruikt: taginfo

[/*] [*][key border_type](https://wiki.openstreetmap.org/wiki/Key:border_type)
  • inconsistent gebruik

  • wordt niet gebruikt door Nomatim (geocoding, naam → coordinaat)

  • border_type=district wordt zelfs expliciet afgeraden

[/*] [*]boundary=place
  • heeft geen wiki

  • laag gebruik taginfo

  • boundary=place + place=[list=]

  • komt (vrijwel) niet voor in combinatie met boundary=place

  • place=* is problematisch als het op een area staat (wordt niet goed weergegeven)

  • er wordt gesteld dat admin_level=* moet worden toegevoegd voor door de overheid bepaalde plaatsen

[/*] [/list][/*] [/list]

Wat sebastic, volgens mij, zegt is dat de boundary=administrative + admin_level=* gebruikt kan worden voor wijken/buurten.
Maar dan moeten de grenzen wel hiërarchisch kloppen met de automatisch geïmporteerde grenzen (1…10 voor zover gebruikt).
Bovendien moeten de grenzen gedefinieerd zijn door de overheid.
En de grenzen moeten ook onderhoudbaar zijn (dit impliceert automatische import - of niet?).

Het gebruik van landuse=residential + name=* is niet gewenst voor grenzen.

Het gebruik van border_type is problematisch.

Mijns inziens, zouden grenzen die niet precies in de hierarchie vallen een andere boundary=* moeten hebben.

De grenzen van waterschappen (volgens de wiki boundary=administrative + admin_level=5) passen niet in de hiërarchie.
Voorstel boundary=water_management?
Worden de waterschapsgrenzen automatisch geimporteerd?
(hmm, ik zie geen waterschapsgrenzen, mis ik wat?)

Volgens het CBS krijgen zij de gemeentegrenzen uit de BRK.
Wijk- en buurtgrenzen worden (via opgave van gemeentes) in een shape file beschikbaar gesteld (licentie probleem: bronvermelding; misschien ook beschikbaar via PDOK - moet ik nog uitzoeken).
Met de CBS gegevens op wijk/buurt niveau zijn nog wel problemen:

  • namen zijn lokaal anders of niet in gebruik
  • geometrieën kloppen niet
    Rechtvaardigen deze problemen een andere hiërarchie voor buurten/wijken met boundary=statistical?
    (Mijns inziens niet, vermits ze niet door de andere grenzen heengaan - maar daar mag je wel van uitgaan, hoewel het oppassen blijft met verschillende bronnen/periodes.)
    Is hiervoor dan ook een procedure nodig? (analoog aan die van de BAG-import)

Bij voldoende consensus ben ik wel bereid om wiki pagina’s hierover aan te maken (Nederlands en/of Engels).
Daarvoor zou ik eigenlijk ook nog willen weten welke bronnen gebruikt worden voor de automatische import(s).
En liefst ook met uitleg hoe je die importeert.
Kun jij dit aanleveren, sebastic?

Opmerkingen/aanvullingen, ik hoor ze graag.

Nee, dat moet juist niet gebruikt worden voor CBS wijken & buurten, zoals beschreven in de OP.

Wanneer de CBS wijken en buurten in OSM opgenomen worden moet hier goed over nagedacht worden, het is een vorm van import. Tooling is vrijwel essentieel om de OSM data te genereren, automatische import is bijzonder onwenselijk.

Voor waterschappen was er voorheen een admin_level gereserveerd, maar ze waren nooit daadwerkelijk toegevoegd in OSM, zoals beschreven in de OP.

Dat of iets anders dan boundary=administrative.

Er is geen automatische import van administratieve grenzen in Nederland.

De woonplaats, gemeente en provincie grenzen worden onderhouden op basis van de BAG woonplaatsgrenzen.

Voor de BAG is de inspireadressen dataset beschikbaar op PDOK. Deze GML data wordt in een PostGIS database geimporteerd met NLExtract. Met behulp van ogr2osm en wat custom tooling wordt OSM data (per provincie by default) gegenereerd uit deze database. osmosis wordt gebruikt om een tweede database bij te houden met de OSM data voor Nederland. Deze database wordt gebruikt door een script om OSM files te genereren (per provincie by default) met alle administrieve grenzen en daaraan verbonden objecten. Deze OSM data files worden in JOSM geladen samen met de OSM files voor de BAG woonplaatsgrenzen en grenzen die in BAG nieuwer zijn dan in OSM worden vervolgens handmatig aangepast.

Nu we het toch een beetje over het taggen van woonplaatsen en grenzen hebben…
Ik heb in Limburg enkele woonplaats nodes als label aan de grenzen toegevoegd.
Het vreemde is, wanneer ik nu een town opzoek wordt dit mooi als 1 geheel weergegeven,
Bij een village zie ik nogsteeds de node en de stadsgrens als 2 verschillende resultaten.

village (Limbricht): https://www.openstreetmap.org/relation/1421977
town (Geleen): https://www.openstreetmap.org/relation/1421667

EDIT: taalfouten, links, ik was niet helemaal wakker

Dank sebastic voor je uitleg. Die komt vast nog eens van pas.
Niet een procedure die je zo even uitvoert.

Ik noem het automatische import omdat er scripts aan te pas komen. Maar ik zie dat de laatste stap handmatig is.
Laten we zeggen semiautomatisch.

Een paar punten van aandacht:

  • de waterschapsgrenzen admin_level=5 lopen niet mee in de hierarchie; in de OP staat er niets over.
    Er staat wel iets over op de wiki over boundary=administrative (waar naar OP verwezen wordt).
    Ik vind sowieso dat adminstrative + admin_level niet passend zijn voor de waterschapsgrenzen.
    Zonder tegenbericht zal ik het uit de wiki halen.

  • Je noemt consequent CBS wijken & buurten.
    Maar deze data wordt aangeleverd door de gemeentes en gebundeld door CBS. Het is dus niks statistisch, per se.
    De grenzen van de wijken & buurten zouden moeten passen in de gemeente grenzen van admin_level 10 en lager.
    Zoals jij al aangeeft, in een reactie, is dat niet altijd zo.
    Er zal hier en daar een handmatige aanpassing nodig zijn - zoals ook opgemerkt door JeroenHoek betreffende Leeuwarden.

  • de wijk/buurt grenzen zijn conceptueel passend in dit schema.
    Met een zelfde soort, semiautomatische, methode zou je wijken & buurten kunnen invoeren.
    Stel dat er een import gedaan kan worden op verzoek, zoals bij BAG-import.
    En stel dat jouw import de grenzen van admin_level > 10 (die vastzitten aan die van <= 10) kan wijzigen (zonder verder overleg).
    Wat maakt dan nog dat jij vindt dat het in een ander schema moet? Iets technisch misschien?

Wijken en buurten hebben geen officiele bestuurslaag, dat is een vereiste voor boundary=administrative in Nederland. Woonplaatsen zijn hierop de uitzondering omdat het de officiele verdeling van de gemeentes is. Dit alles is beschreven in de OP.

Ik hanteer de naam CBS Wijken & Buurten omdat dit de naam van de dataset is die in principe gebruikt wordt voor de betreffende geometrieen.

Ik vind 414 relaties met deze combinatie in Nederland. Zo zeldzaam is het dus niet. Het is ook een tag die logisch weergeeft wat voor grens het is, namelijk de grens van een plaats (bijv. wijk of buurt).

Boundary=statistical impliceert dat deze grenzen voor statistische doeleinden worden gebruikt. Dat is alleen het geval bij een CBS-wijk/buurt, niet bij een wijk/buurt die alleen gebruikt wordt door lokaal bekenden of het gemeentebeleid.

Daarom moet je ook een place-node toevoegen. Als je de grenzen daarna als relatie invoert i.p.v. als vlak, dan kun je m.b.v. de rol label de place-node aan de plaatsgrenzen koppelen.

In principe is een waterschap een bestuursniveau net als provincies en gemeenten, dus boundary=administrative. Het zou wel raar zijn deze grenzen op de kaart door de provincie- en gemeentegrenzen te zien lopen, maar feitelijk klopt het wel.

Wijken & buurten worden gedefinieerd door de overheid en vallen dus ook onder boundary=administrative.
Bovendien hebben wijken en buurten een logische, hierarchische relatie met gemeentes.
Daarom moeten wijken en buurten ook een admin_level hebben.

Dat het nodig is om een bestuurslaag te hebbben voor boundary=administrative haal ik alleen uit de OP.
Verder zie ik dat nergens. Wat vinden anderen hiervan?

De waterschapsgrenzen zijn inderdaad onafhankelijk van de andere grenzen. Daarom moet daar ook zeker geen admin_level bij.
Tot op zekere hoogte zijn ze administratief gedefinieerd, Maar ze zijn ook geografisch bepaald, door rivieren etc.
Vandaar dat ik boundary=administrative voor de waterschapsgrenzen ook al enigszins ter discussie stelde.

Ik snap de naamgeving maar de data komt van de gemeentes af. Het CBS verzamelt die.
In theorie kan je die ook bij de afzonderlijke gemeentes ophalen.
@A67-A67 boundary=statistical voor deze wijk & buurt grenzen is dus niet van toepassing.

Kan het niet nagaan - die overpass query geeft een timeout. Maar ok.
Ik keek naar de taginfo values voor boundary.
1194 x wordt boundary=place wereldwijd gebruikt.

Sowieso is er geen eens een wiki voor boundary=place. Dus waarom wordt dit aangeraden?

Een place-node kan inderdaad handig zijn.

Dit geldt toch voor alle grenzen? Veel grenzen worden bepaald door geografische elementen, zoals rivieren en bergen. Dat is ook het geval bij waterschappen. Daar zijn de grenzen vaak waterscheidingen, rivieren en landscheidingen.

Daarmee is het de 18e meest voorkomende waarde van boundary en geen van de nummers 1 t/m 17 lijkt toepasbaar voor wijk- en buurtgrenzen.

Het wordt aangeraden omdat het:
a) De meest correct beschrijvende tag is. Het zegt letterlijk dat het de grens van een plaats is. In OSM gelden wijken en buurten als plaatsen.
b) Het de meest gebruikte tag is om wijkgrenzen te taggen. Wijkgrenzen taggen gebeurt relatief weinig, waardoor totaal aantal weinig lijkt.

Voor documentatie lijkt het me inderdaad handig om een wiki-pagina van boundary=place aan te maken.