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.

AutoCAD blocks als MapGuide 6.5 symbolen

Vorige week kreeg ik de vraag: “hoe gebruik ik AutoCAD blocks als MapGuide 6.5 symbolen ?

In de huidige systeem configuratie worden AutoCAD tekeningen ge-exporteerd naar diverse SDF-files en Access-tabellen. De teksten en punt-objecten worden eerst ge-explodeerd om vervolgens als lijnstukjes te worden ge-exporteerd. Er waren dus nooit echte punt-symbolen gedefinieerd tbv. MapGuide.

Momenteel worden de tekeningen naar Oracle Spatial ge-migreerd ( als onderdeel van een BGT-project ). Daarbij worden de teksten en punt-objecten vanuit AutoCAD Map opgeslagen als Points in de database. De bijbehorende teksten worden als attributen weggeschreven en kunnen als labels worden weergegeven. Echter voor de punt-symbolen wil men overeenkomstige symbolen als in CAD definieren, zodat de kaart in de web-viewer er hetzelfde uit komt te zien.

MapGuide 6.5 kent een Symbol Manager hulpprogramma, hiermee kan een bibliotheek van symbolen worden aangelegd.
AutoCAD kent een Export commando, waarmee AutoCAD blokken naar WMF-files kunnen worden ge-exporteerd.

Hiermee was de vraag opgelost.

CAD en GIS, het juiste gereedschap voor de klus ( II )

Afgelopen week kreeg ik de vraag om een Shape-file en een Excel-sheet met elkaar te koppelen en als resultaat een nieuwe Shape-file te maken met slechts een deel van de attributen.

In de Shape-file zat de geometrie van wegvakken, met als attributen: weg-nummer, weg-vak-nummer en weg-vak-onderdeel-nummer. In de Excel-sheet zaten diezelfde nummers en nog meer detail informatie van de wegvakken. Deze Excel-sheet was geexporteerd vanuit wegbeheer software.
Als de AutoCAD Map gebruiker dan ook nog een senior ArcGIS gebruiker is, dan heb je als consultant een aardige uitdaging.

In de vorm van een handson workshop de volgende zaken opgepakt:

AutoCAD Map FDO Create a JoinVoor het linken van de beide bestanden aan elkaar, gebruiken we de FDO-functie: Create a Join.
Hiervoor moeten Shape-file en Excel-sheet beide als FDO-source aan AutoCAD Map gekoppeld zijn en er moeten één of meerdere gemeenschappelijke velden zijn om te kunnen koppelen.

Om een FDO-connectie te kunnen leggen met de Excel-data is het handig om deze even te importeren in een Access-tabel. Vervolgens kan de FDO-connectie naar die Access-tabel gelegd worden dmv. de volgende Connection String:
Driver={Microsoft Access Driver (*.mdb)};DBQ=pathnamefilename.mdb
Door de Excel-data even in een Access-tabel te importeren is het nml. ook mogelijk om de velden die gebruikt worden voor de koppeling van hetzelfde database type te maken ( Text of Numeriek ).

In het hieronder afgebeelde scherm wordt vervolgens de FDO-connectie naar de Shape-file als Primary table geselecteeerd en de FDO ODBC-connectie naar de Acces-tabel als Secondary table.
Voor de Join worden de volgende velden aan elkaar gelinked:
WEG_NR002 -> Weg
WEGV_NR002 -> Vak
WEGVONR002 -> Ond

In het FDO DataGrid is het samengestelde scherm te zien. Maar om hiervan een nieuwe Shape-file te maken met slechts een deel van de attributen is echter in AutoCAD Map niet zo’n eenvoudige opgave.
Wat in ArcGIS een fluitje van een cent is, blijkt in AutoCAD Map toch nog een hele opgave.

Om hiervan een nieuwe Shape-file te maken, met in de DBF-database de inhoud van het orginele bestand aangevuld met de Excel-sheet, wordt eerst een export naar SDF gemaakt. Deze lokale spatial database bevat de samengestelde structuur.
Met behulp van de FDO Schema Editor kan een nieuwe lege Shape-file worden aangemaakt met daarin alleen die attribuut kolommen die nodig zijn.
Met behulp van FDO BulkCopy functionaliteit kan de inhoud van de SDF-file worden overgezet naar de Shape-file. Hierbij kan een keuze worden gemaakt uit de velden die moeten worden overgezet.

AutoCAD Map FDO Create a Join

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.

CAD en GIS, het juiste gereedschap voor de klus

Een tijdje geleden kreeg ik de volgende email: “Hallo Henny, ik ben verantwoordelijk voor projecten die te maken hebben met beheer en onderhoud van ons duingebied. De ruimtelijke gegevens zijn door GIS collega’s in een Oracle Spatial database gezet. We willen gegevens die te maken hebben met de uitvoering van de onderhoudswerkzaamheden graag direct met een AutoCAD omgeving kunnen beheren. Kun je mij hiermee op gang helpen ?

Ik denk dat dit een herkenbare situatie is bij bedrijven met een CAD en een GIS-afdeling. Vaak wordt informatie tussen die afdelingen uitgewisseld door Shape of DXF bestandjes over en weer te sturen, terwijl AutoCAD Map mbv. haar FDO-functionaliteit rechtstreeks kan koppelen aan de Oracle Spatial database.

In de vorm van een handson workshop de volgende zaken opgepakt:

Om te beginnen een koppeling met de ArcGIS tabellen in Oracle gemaakt als een zgn. Foreign Datastore. Hiermee worden tabellen bedoeld die niet door AutoCAD Map zelf zijn aangemaakt en daardoor geen FDO-metadata bevatten. De data komt prima op het scherm, maar het werken met bijv. de Style Editor om thema kaarten te maken is ietwat omslachtiger.

Daarom in een nieuw Oracle schema mbv. FDO’s Schema Editor de gewenste feature tabellen aangemaakt, zodat er automatisch FDO-metadata wordt aangemaakt. Hierbij een keuze gemaakt welke kolommen informatie bevatten die voor beheer en onderhoud taken nodig zijn en welke konden worden geskipped. Daarna mbv. BulkCopy functionaliteit de data overgezet vanuit de bestaande tabellen.

In de ArcGIS tabellen werd bijv. de oppervlakte van een polygoon mbv. een database trigger berekend vanuit de geometry. In AutoCAD Map worden de database attributen getoond en bewerkt mbv. een Data Table. Hieraan kunnen ook zgn. reken-kolommen worden toegevoegd ( zie afbeelding ). Hiermee is direct de oppervlakte van een polygoon vanuit de geometry beschikbaar.

Verschillende thema kaarten aangemaakt en deze style instelllingen opgeslagen in Layer definitie bestanden, zodat deze gemakkelijk in bestaande CAD-tekeningen kunnen worden her-gebruikt.

Create a Calculation