BGT-bronhoudergrens, een pragmatische aanpak

Ik heb inmiddels een aantal posts geschreven over het BGT-project waar ik momenteel bij betrokken ben.
Een steeds terugkerende onderwerp, als je met mensen spreekt over de BGT, is: “Waar leggen we de bronhoudergrens?

In eerste instantie wordt gedacht aan de kadastrale grens. Die komt per slot van rekening ook uit een authentieke registratie en voor twee gemeenten onderling zou dat wellicht een prima bronhoudergrens zijn. Ik ben betrokken bij een project bij de provincie en die “doorsnijdt” de gemeenten met haar provinciale wegen en daarvoor komt de kadastrale grens minder in aanmerking.

AutoCAD Map - bestaande GBK-data in DWGGebruikers van de provinciale kaart zijn o.a. de eigen diensten weg- en groenbeheer. Naast de topografie, die in een strook langs de weg wordt ingemeten, zijn het vooral de weg- en groenobjecten die van belang zijn voor deze beheerkaarten.
Soms wordt er meer groen beheerd dat eigendom is van de provincie – denk aan een bermsloot die in z’n geheel gemaaid wordt, terwijl de kadastrale grens door het hart van de sloot loopt.
Momenteel worden veel kruisingen vervangen door rotondes, daarvoor is meer ruimte nodig en zullen stukken grond van gemeenten of particulieren moeten worden aangekocht. Het vaststellen en inmeten van de nieuwe kadastrale situatie gebeurt vaak later en daardoor is de kadastrale grens niet (meer) actueel.

AutoCAD Map - nieuwe BGT-data vanuit Oracle Spatial met daar bovenop bestaande GBK-data in DWGBinnen ons project hebben we nu gekozen voor een pragmatische aanpak: we gebruiken de buitenste topografische lijnen in de stroken kaarten om de vlakken te vormen. In sommige gevallen moeten we hulplijnen toevoegen om de vlakken te sluiten. Als de bronhoudergrens bepaald is, zal blijken welke vlakken moeten worden opgeknipt.
De huidige beheergrens en kadastrale grens laten we momenteel volledig buiten beschouwing. Ook gebouwen die buiten het beheergebied vallen en gedeeltelijk op de kaart staan ter referentie, worden niet meegenomen evenals aanzetten van rasters, sloten en zijwegen die gedeeltelijk op de kaart staan, maar buiten het beheergebied vallen.

Met deze aanpak kunnen de kaarten objectgericht worden gemaakt en kan de geometrie van de weg- en groenvlakken gekoppeld worden aan de beheerdata.
Ondertussen wordt overleg gevoerd met Stichting GBKN, gemeenten, waterschappen, Rijkswaterstaat en het Ministerie van VROM over de bronhoudergrens.

BGT-bespreking met Geonovum

In de vorige post over het BGT-project waar ik momenteel bij betrokken ben, schreef ik over belangstelling vanuit diverse lokale & landelijke overleg structuren en over een geplande bespreking met Geonovum.
Hier volgt een hele korte samenvatting van deze bijzonder interessante meeting.

Na een introductie van het werkproces (zie vorige posts) werd uitgebreid gediscussieerd over de vraag: “waar leggen we de bronhoudergrens voor de BGT?”

AutoCAD Map - bestaande GBK-data in DWGDe huidige tekeningen zijn stroken kaarten langs provinciale wegen, met daarop de wegen, fietspaden, sloten, terreinen enz. Er staat meer topografie op de kaart dan strikt binnen het eigendom van de provincie valt.
Als we als bronhoudergrens de kadastrale eigendomsgrens nemen, dan hebben we in elk geval te maken met een polygoon die in een andere basis registratie is vastgelegd. Echter in de pilot is gebleken dat er soms gebieden buiten de eigendomsgrens toch in beheer zijn bij de provincie, terwijl ook het omgekeerde het geval is. Het is ook niet zo praktisch om de bronhoudergrens samen te laten vallen met bestaande lijnen, omdat er anders lijnen wegvallen bij het structureren en vlakvormen.
Op dit moment is het idee om gebruik te maken van virtuele grenzen, waarbij het voor de toekomst van belang is om deze beheergrens voor de BGT als authentieke grens in de registratie op te nemen.

Uit de pilot is gebleken dat er voldoende classificaties in de huidige tekeningen zijn opgenomen om de grenzen van de IMGeo-vlakken te bepalen. Er worden centroides gebruikt om de vlakken zelf te classificeren.

AutoCAD Map/FDO - BGT pilot-data vanuit Oracle SpatialEr bestaat behoefte om meer attributen aan de centroides toe te voegen, dan strikt noodzakelijk volgens het IMGeo-model.
Het is natuurlijk geen enkel probleem om meer informatie in de eigen database op te slaan, als tijdens de uitwisseling naar het centrale register maar een vertaling naar de gewenste attributen plaatsvindt.
Ook onderscheidt de provincie meer puntsymbolen op haar kaarten, dan strikt noodzakelijk.
Eveneens geen probleem.

Natuurlijk kunnen dit soort uitbreidingen ook doorgegeven worden aan Geonovum. Dan kan men altijd bekijken of het model zou kunnen worden aangepast. In de zomer van 2010 zal het BGT model worden vastgesteld en komt er een nieuwe versie van IMGeo.

Van AutoCAD Map DWG naar BGT conform IMGeo ( deel 2 )

Ik heb al een aantal posts geschreven over het BGT-project waar ik momenteel bij betrokken ben.

Het structureren van de bestanden gaat voorspoedig, de eerst test-migraties met AcClassify naar de Oracle Spatial database hebben vorige week plaatsgevonden en de data kan worden weergegeven in ArcGIS-desktop en de webviewer.
Dat ik even was vergeten om de limits van de database goed in te stellen en dat de Oracle tables nog wel even in SDE moesten worden geregistreerd, zijn peanuts 😉

Vanuit diverse lokale & landelijke overleg structuren wordt er over onze schouders meegekeken, want de BGT houdt (bijna) iedereen bezig.
Over twee weken is er een bespreking waarbij ook de mensen van Geonovum – de “bedenkers” van het IMGeo-model – zullen aanschuiven, want ook zij hebben belangstelling voor feedback vanuit het werkveld.

AutoCAD Map – Centroides, Topology en Polygonen

In mijn vorige post AutoCAD Map – Break, Trim en CleanUp heb ik het structureerproces van de tekeningen besproken.
Nu ga ik het over het classificeren en genereren van de vlakken hebben.

centroidesAls eerste zijn er centroides gemaakt, AutoCAD points die als attribuut informatie de verplichte velden uit het IMGeo-model bevatten.
Zo’n centroide voor een Wegdeel bevat bijv. de attributen IDentificatie, objectBeginTijd, status, relatieveHoogteligging, typeWeg enz.
Daarnaast zijn er o.a. centroides voor Spoorbaandeel, Waterdeel, Terreindeel, Kunstwerkdeel en Pand. Deze Panden komen uit de Basisregistratie Adressen Gebouwen ( BAG ) overigens.

Vervolgens moet er een Polygon Topology worden gemaakt. Hierbij wordt ook weer gebruik gemaakt van een wizard interface, waarbij de gestructureerde lijnen de links vormen waaraan de centriodes worden gekoppeld.
Mochten er nog lijnen niet netjes gesloten zijn, dan geeft het Topology proces een foutmelding. Evenzo als er centroides zijn vergeten of dubbel geplaatst.
Het Topology model wordt omgezet naar MPolygons, waarbij de IMGeo classificaties van de centroides er naartoe worden overgezet. Deze MPolygons worden als polygonen in de Oracle database gezet mbv. AcClassify.

maar daarover meer in een volgende post

Van AutoCAD Map DWG naar BGT conform IMGeo

Momenteel ben ik betrokken bij een AutoCAD BGT pilot project. Aanleiding voor het uitvoeren van deze pilot is de invoering van de Basisregistratie Grootschalige Topografie ( BGT ) geclassificeerd conform het Informatiemodel Grootschalige Geografie ( IMGeo ).

Undershoot - OvershootOm vanuit lijngerichte tekeningen naar een vlakgerichte database te kunnen migreren, zullen de lijnen, die de vlakken moeten gaan vormen, aan geometrische voorwaarden moeten voldoen.
De lijnen moeten netjes op elkaar aansluiten. Is één van de lijnen te kort, dan is er mogelijk sprake van een undershoot. Schieten de lijnen onder elkaar door en is er ter plaatse van het snijpunt geen tussenpunt, dan is er mogelijk sprak van een overshoot.
In beide gevallen zullen deze lijnen moeten worden opgeknipt, zodat er snijpunten worden gemaakt. Anders kunnen er namelijk geen vlakken worden gevormd.

AutoCAD Map kent hiervoor CleanUp functionaliteit om de tekeningen (semi)automatisch op te schonen en Topology functionaliteit om vlakken te vormen.

in de komende posts zal ik meer inhoudelijk ingaan op dit werkproces