Omdat ik nieuwsgierig was naar de kwaliteit van gemeentegrenzen in OpenStreetMap, heb ik een vergelijking gemaakt tussen de grenzen in OSM en de bestuurlijke gebieden zoals aangeboden door PDOK: https://www.pdok.nl/introductie/-/article/bestuurlijke-gebieden
De eerste conclusie is dat het best goed overeenkomt. Tegelijkertijd zijn er ook verschillen in de grenslijnen. Toegegeven, over het algemeen betreft het enkel kleine verschillen. Aan de andere kant betreft dit ook de landsgrens, wat juist wel weer van groot belang is.
Enkele voorbeelden (paars is van PDOK, geel/rood betreft de lijnen in OSM):
Kornwerderzand, sluizen in de Afsluitdijk:
In deze geopackage heb ik de verschillen aangegeven, waarbij ik onderscheid heb gemaakt tussen een afwijking > 1m en een afwijking > 0,01 m; de laatste zijn er uiteraard veel meer.
Is het wenselijk de geometrie van de gemeentegrenzen aan te passen naar die van PDOK?
Zo ja, is er een mogelijkheid om dit redelijk efficiënt te kunnen doen rekening houdend met alle gekoppelde relaties e.d.?
Ik weet niet wat de beste en handigste bron is, maar heb in het verleden wel eens per ongeluk een gemeentegrens versleept. Dergelijke foutjes (ik zal denk ik niet de enige zijn) kunnen een verklaring zijn van afwijkingen tussen OSM en andere bronnen.
(zelf zet ik grenzen dan ook vaak uit met een filter in JOSM)
Foutjes kunnen ook dan nog ongemerkt gaan, zeker als gemeentegrenzen vastzitten aan andere type objecten.
Praktische tips om zulke onbedoelde wijzigingen te voorkomen zijn welkom!
(zou het goed vinden als het wijzigen van elementen zoals gemeentegrenzen voorbehouden zou zijn aan een beperkt aantal gebruikers met speciale rechten..)
Ik heb in Josm een filter staan dat per default enabled is:
boundary~"(administrative|place|low_emission_zone|national_park|protected_area)" or landuse~"(industrial|residential|commercial|retail|farmyard|static_caravan|greenhouse_horticulture)" or leisure~"(park|sports_centre)" or amenity=hospital or man_made=pipeline or power=cable
Daarmee worden alle deze objecten “verborgen”, dat is je ziet ze nog steeds als grijze lijntjes maar je kan ze niet meer editen. Als je ook H(ide) enabled dan zie je ze helemaal niet meer
Dit truukje had ik nog nooit gebruikt, dus ik moest wel ff zoeken. Het blijkt dat er een venster “Filteren” is, waarin je regels kan zetten om objecten uit te filteren dwz laten vergrijzen of verdwijnen uit de actieve display. Ik ga dit ook maar eens aanzetten, want ik heb behoorlijk veel last van al die overgooiers.
PS Aangeet, als je t eenmaal weet is het heel logisch en gemakkelijk. Ik ga wel een paar dingen uit het filter halen, bv farmyards wil ik wél zien en aanpassen.
Het lijkt me alsof de afwijking_1m laag de OSM coördinaten heeft, handiger zou het zijn als het de PDOK coördinaten heeft zodat je de verschillen kan zien.
Ja, prima idee om de grenzen aan te passen a.d.h.v. PDOK.
Hoe ik het zou doen (niet 100% of het ook werkt):
Zet de PDOK data in .osm formaat
Laad het pdok.osm bestand en de bestaande data in Josm
Knip het stuk dat je wilt vervangen zowel in de bestaande OSM als de PDOK osm uit
Zorg ervoor dat bij het uitknippen van de bestaande OSM het gewenste stuk de osmid houdt, de overige stukken “id 0”
Selecteer zowel het OSM en het PDOK deel en kies More Tools → Replace Geometry
Je krijgt dan een “Conflicts when combining ways”
Selecteer Keep voor alle boundary relaties
Je zou ook een complete OSM “grensweg” kunnen vervangen dat scheelt opknippen maar je moet wel de OSM data voor de hele grensweg downloaden en je moet nog steeds de PDOK osm data op maat knippen.
Executive summary: Nee, het is niet wenselijk om de gemeentegrenzen aan te passen naar die van PDOK.
De administrative boundaries in OSM worden opgebouwd uit de woonplaatsgrenzen, gemeentes zijn verplicht hun gemeente op te delen in aansluitende woonplaatsen, hier kunnen fouten in optreden waardoor gaten ontstaan omdat elke woonplaats een gesloten ring is en de linestrings tussen de woonplaatsen niet hergebruikt worden zoals in OSM. Hier gebruiken we ons eigen inzicht wat de beste oplossing voor OSM is, vaak wordt de geometrie van de meeste recent bijgewerkte woonplaats gebruikt tenzij de andere zichtbaar logischer loopt.
Het is mij niet duidelijk hoe de bestuurlijke grenzen worden opgebouwd, ik vermoed dat daar normalisatie op toegepast wordt waardoor deze een lagere resolutie hebben dan de BAG woonplaats grenzen (minder points per linestring).
Een analyse van de BAG woonplaatsgrenzen en de bestuurlijke grenzen toont de verschillen die je in OSM ziet hoogst waarschijnlijk ook omdat de BAG woonplaatsgrenzen nagenoeg identiek in OSM staan. Versleepte grenzen in OSM zijn goed mogelijk waar die aan (water)wegen zijn genoopt, en ook de lansgrens zal waarschijnlijk door de buren zijn aangepast daar zullen we nooit dezelfde geometrie voor gebruiken zolang dat in Nederland al niet lukt tussen naburige gemeentes.
Wat mij betreft is het nog steeds een goed idee een goed overzicht te krijgen wat betreft de grootste verschillen en daar verder op in te gaan, 10 meter verschil vindt ik significant maar zeker met de landsgrens zo het wel goed zijn om dat af te stemmen met de buren.
De geopackage bevat niet de data van PDOK, deze is direct vanaf de website te downloaden en te openen in (Q)GIS. En daarmee is het verschil met de OSM-gegevens te zien.
Wat betreft de woonplaatsen: in de BAG-geopackage worden exact dezelfde woonplaatsgrenzen als die in de bestuurlijke gebieden weergegeven. Het lijkt me toch dat deze normatief zijn?
Wat betreft het ‘algoritme’: ik heb om de PDOK-grenzen een buffer van 0,01 m respectievelijk 1 m gelegd, en de OSM-grenslijnen in stukken van 50 m opgedeeld. Vervolgens heb ik die stukken die niet binnen de buffer vallen opgenomen in de 2 lagen afwijking 1 / 0,01 m.
Bedenk wel dat als grenzen gekoppeld zijn aan (vaar)wegen of andere objecten, ze nog steeds verschoven kunnen worden als die objecten aangepast worden.
Ik weet overigens niet in hoeverre het koppelen voorkomt, en waarom dit door sommigen gebeurt…
Als reactie op Emvee’s filter post.
Weet iemand of in iD-editor ook zulke filters bestaan ?
Mooi dat ervaren OSM-NL forum-leden nu geen per ongelukke edits in grens definitie’s kunnen maken maar ik hou toch mijn hart vast voor alle edits die nu gedaan kunnen worden die:
én deze info van Emvee niet hebben maar wel de JOSM-editor gebruiken.
ID-editor gebruiken immers dit is nog steeds de default uitrusting van alle web-based edits.
Met andere woorden:
mooi dat er een filter bestaat in JOSM maar zou het niet logischer zijn in de JOSM-editor dit filter als default zo in te richten dat je boundaries níet kan aanmaken/wijzigen tenzij je dat recht:
A. of hebt, zoals multimodaal al eerder in post 2 opmerkte:
“(zou het goed vinden als het wijzigen van elementen zoals gemeentegrenzen voorbehouden zou zijn aan een beperkt aantal gebruikers met speciale rechten..)”
B. of ,indien je dat recht niet hebt, tijdelijk kan krijgen met een automatisch kattebelletje naar standaard rechtmatige als er mutaties hebben plaatsgevonden…
Dat laatste met bijvoorbeeld een interactie waarschuwingsvraag aan de niet standaard-rechthebbende: ‘make this boundary edit possible (Y/N) ?’
Deze bovenstaande oplossing in punt 1 ook in de iD-editor goed op te laten lossen ?
Immers zou een heleboel newbie-edit ellende oplossen !
Top !
Ik ga meteen aan de gang, want het is me kwa lands- en/of provincie en/of gemeentegrens nog niet gebeurt maar wil ook niet dat dat in de toekomst me ooit kan gebeuren !
Ik wil echter wel dat grenzen wél getoond kunnen worden maar niet per ongeluk aangepast…
Zoals ik het in de instellingen lees voorziet het daarin níet in…
Er wordt geen normalisatie of andere techniek op toegepast. De grenzen worden vastgesteld door de gemeentes/provincies. In de meeste gevallen loopt de grens gelijk met de kadastrale perceelsgrenzen. Binnen een gemeente zijn 1 of meer kadastrale gemeentes. De optelling van al deze percelen is de gemeentegrens. Omdat de woonplaatsen per definitie gebiedsdekkend zijn, zouden de gemeentegrens en woonplaats grens op dezelfde plek moeten liggen. De praktijk is soms anders.
Juist om het feit dat de praktijk anders is, is naar mijn mening dit draadje gestart…
Zou fijn zijn dit links of rechts-om recht te zetten & mijn voorkeur is dan om in ieder geval OSM edit ongelukjes zo mooi mogelijk af te vangen door dat bij de basis (zie mijn eerdere post) aan te pakken.
Scherp gezien! Ik heb daar inderdaad foutief gebruik gemaakt van clippen van de polygonen van de gemeentes aan de hand van de PDOK-landsgrens. Daardoor ontstaat er een lijn die verder niet voorkomt, maar dit kon dus alleen gebeuren bij de landsgrens.
Hierbij een nieuwe versie van het bestand, waarbij deze fout is verholpen.
Als ik kijk naar de >1 m lijnen, zie ik mijn naam op nodes staan.
Deze heb ik onbedoeld verplaatst. Waarbij ik mij de vraag stel, hoe is het zo gekomen. Onbedoeld gelijkmatig de hele lijn (wayid) verschoven? Al kijkend naar de verschuivingsrichting en verschuivingsafstand van de verschillende nodes.
Ik weet, dat ik te maken had met meerdere lijnen en een path over die grenslijn. Iets met node van path, overgang track naar path en kruizingen en een andere grenzen (bos, gebied) willen verschuiven. Ik meen ook dat zaken aan elkaar zaten.
Dit is dan ook nog eens provinciale grens.
Ik vindt het nu niet correct om de node op het oog nu terug te schuiven naar een kadastrale perceelsgrens, hoek, omdat bij een node, grenstak, mijn verplaatsing, de oosprong (sebastic import) niet op de kadastrale hoek lag.
Pewu history viewer
Waarschijnlijk wel op de lijn maar niet op de hoek.
Dat koppelen kom ik ook vaak tegen, ik neem aan omdat de grens overeenkomt met een waterloop, weg, natural gebied of landuse gebied. De gedachte zal zijn: als het element verandert, verandert de grens wel mee. En als dat eenmaal gekoppeld is zonder dat je het ziet, dan verandert een mapper het heel gemakkelijk nog verder, dus ik heb grenzen gezien die langs een kronkelend binnenwater een stad in lopen en aan de andere kant van het water weer helemaal terug!
Ik probeer de dader dan niet binnensmonds uit te kafferen, want voor hetzelfde geld heb ik het zelf gedaan…
