AutoCAD Map Archives - Page 8 of 12 - vanderpol-consulting.nl

5 April, 201011 February, 2018

AutoCAD® Map 3D 2011 – wat is nieuw(s)

AutoCAD^® 2011 software
Gebouwd op het AutoCAD 2011 Plaform. AutoCAD Map 3D 2011 mapping software bevat alle functionaliteit van AutoCAD^® 2011 CAD software.

New Point Cloud Tools
Als eerste uitgebracht als een Autodesk^® Subscription Advantage Pack voor AutoCAD Map 3D 2010, maken de nieuwe point cloud tools het mogelijk om grote sets van 3D laser scanning/LIDAR data ( vaak met miljoenen punten ) te importeren en te visualiseren binnen de AutoCAD Map 3D software. Je kunt deze point clouds nu ook in laten kleuren op basis van LAS classificatie, hoogte, of intensiteit. Point clouds kunnen worden gebruikt om DEM surfaces aan te maken.

Enhanced Workflow Capabilities
Gebouwd op de functionaliteit die in AutoCAD Map 2010 is geïntroduceerd en gebruik makend van de Windows^® Workflow^tm Foundation, is het in AutoCAD Map 2011 nog gemakkelijker om repeterende taken uit te laten voeren. Nieuwe Workflow taken maken het mogelijk om connecties te leggen met elke vector data source; aanpassen en opslaan van feature layer stijlen; uitvoeren van AutoCAD^®, AutoCAD Map 3D, en AutoCAD^® Raster Design functies.

New & Enhanced Data Support
Met AutoCAD Map 3D 2011 kun je werken met een varieteit aan data. AutoCAD Map 3D 2011 omvat ondersteuning voor ESRI^® ArcSDE^® 9.3.1 (32- en 64-bit), Oracle® 11gR2, Microsoft^® SQL Server^® 2008 SP1, PostGIS 1.3.6, PostgreSQL 8.3.7-1, en SQLite 3.6.14.

26 February, 201011 February, 2018

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.

Gebruikers 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.

Binnen 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.

15 February, 201011 February, 2018

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.

31 January, 2010

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 Join Voor 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

18 December, 200911 May, 2019

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?”

De 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.

Er 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.