3D geoinformatie gebruiken in Revit – hoe gaat dat?
Als je deze blog helemaal weet uit te lezen heb je zeker eens met Autodesk Revit geworsteld bij het inlezen van de gratis en openbare geodata die in Nederland beschikbaar is. Misschien ben je er wel mee opgehouden omdat het te lastig was en de resultaten niet goed. Dan is deze blog je kans om dat toch nog goed te maken.
We beschrijven twee verschillende datasets, de 3D BAG die door de afdeling 3D Geoinformation van de TU Delft en het 3D Basisbestand van het Kadaster. De 3DBAG is gemaakt op basis van de Basisregistratie Adressen gebouwen (BAG) plus de ruwe laserscan data afkomstig van het Actueel Hoogtebestand van Nederland (AHN). Het bevat alle in de BAG bekende gebouwen van Nederland in LoD 2.2. Het werk van de TU Delft is uniek in de wereld.
Daarnaast hebben we het 3D Basisbestand van het Kadaster ingeladen dat minder detail bevat (LoD 1.2) maar wel (veel) actueler is.
De tooling in deze bijdrage is de CityJSON plugin van TU Delft voor 3D gebouwen en -topografie. Deze tool is te downloaden via de site van Autodesk, in de appstore. Er is ook een kort instructiefilmpje beschikbaar op youtube. Met deze tool heeft de TU Delft laten zien mee te denken met de gebruikers. Het kan trouwens wel even lastig zijn de tool goed te installeren vanwege firewalls en andere beveiligingen. Maar goed, uiteindelijk lukt dat - bij ons met Revit versie 2023.
De plugin converteert geometrie vanuit CityJSON formaat en bijbehorende attribuutdata naar Revit objecten. Daardoor krijg je als gebruiker interessante data tot je beschikking als je bijvoorbeeld de 3D BAG gebruikt. Vooral vanuit stedenbouwkundig oogpunt is dat wenselijk. Pand_id, geregistreerde maaiveldhoogte en bouwjaar zijn typische kenmerken die aan de BAG gekoppeld zijn.
Om de tool te testen richten we ons op de locatie in de omgeving van het Valkhofgebied in Nijmegen. Dat gebied kozen we vanwege de ligging, het mooie uitzicht op de Waal en het is een karakteristiek stukje landschap met veel hoogteverschil. De bijbehorende downloads zijn: 3dbag_v210908_fd2cee53_5578.json voor 3D BAG van de site van TU Delft en 40cz2_02.json (deelgebied 2) voor de 3D basisvoorziening.
3D BAG
Eerst naar de 3D BAG. Het gewenste detailniveau kun je als gebruiker zelf kiezen. Verschillende mogelijkheden zijn beschikbaar en liggen als het ware ‘door elkaar’ in de 3D BAG CityJSON files. Doorgaans wil je als ontwerper zoveel mogelijk details. Dan kies je voor Level of Detail (LoD) met waarde 2.2.
3D basisvoorziening
Bij het importeren van CityJSON bestanden 3D basisvoorziening (Kadaster) kun je kiezen tussen LoD 1.0 en LoD 1.2. Maar de data zit hier anders in elkaar dan bij 3D BAG. Bij 3D BAG gaat het echt om verschillende weergaven van hetzelfde gebouw. Maar LoD 1.0 en LoD 1.2 beschrijven bij de files van Kadaster óf gebouwen (1.0) óf topografie (1.2). Er is dus blijkbaar één LoD per type beschikbaar gesteld met verschillende LoD eigenschappen. Was dit de bedoeling? Een bijkomend voordeel is wel direct dat je meteen de topo kunt filteren. Waarschijnlijk willen de meeste gebruikers toch liever de geometrie uit 3D BAG zien in de omgeving.
Geo-refereren
Nu het lastige gedeelte en een terugkerende bezigheid voor menig Revit ontwerper. Het instellen en grip houden op RD en NAP, oftwel: het geo-refereren van je model. Revit kent veel, te veel, verschillende parameters die de positie van je model kunnen beïnvloeden. Maar in basis werk je ten alle tijden in RD en NAP met de methode van ‘shared coordinates’.
Als eerste importeren we dus de 3D BAG data 5577.json. Dit gaat vlot met een bestand met een omvang van ca. 10 MB. Daar is Revit vrij snel klaar mee. De importer geeft duidelijke aanwijzingen hoe het 0-punt wordt verlegd. Ingezoomd zien we inderdaad het Valkhof liggen! Met Update wordt het nulpunt verlegd. Maar als je in Revit kijkt is er geen RD waarde toegekend aan dit punt. De importer lijkt dus voorbij te gaan aan het geo-refereren van de geometrie.
Het nulpunt van de CityJSON file wordt bij het importeren verlegd naar het interne 0,0 punt in Revit met de optie: Update. Vervolgens geef je dit punt de bijbehorende RD waarde. Je zult nu wel de translatiewaarde in de files moeten opzoeken met het woord ‘translate’ en dit handmatig moeten uitpluizen. Dit is de translatie meegegeven door de dataleverancier. Let op, dit is voor iedere tegel een andere waarde. Onderstaand plaatje geeft de translatie weer voor deze 3D BAG file.
Bovengenoemde waarde 187763560,429062460 (X,Y) voeren we in als ‘Project Basepoint’ via de functie ‘Specify Coordinates at point’. En vergeet vooral niet dat XY andersom genoteerd staat in Revit met N/E en vergeet niet het Revit paperclipje op de juiste stand te zetten.
Het zou erg welkom zijn als de tool dit voor de gebruiker zou doen. Alle data en middelen zijn immers bekend - een kwestie van simpel programmeren!. Wellicht kan dit worden opgenomen in een volgende release. Een tip van onze kant dus.
De Waalkade is mooi in beeld nu. Links in het model ligt het Casino, de tegel is daar geknipt.
Nog een translatie
Vervolgens willen we de 3D topo (LoD 1.2) van kaartnummer 40cz2_02.json van 3D basisvoorziening inladen in dezelfde file. Dat klinkt als een uitdaging en dat is het ook omdat 3D BAG een andere methodiek voor de naamgeving en de grootte van de bestanden gebruikt. Daarom zal het lokale nulpunt wéér een translate ondergaan. De kaartnummers van 3D Basisvoorziening komen trouwens wel overeen met bijvoorbeeld de tegels van AHN. Ware het niet dat deze eigenlijk veel te groot zijn om makkelijk mee te kunnen werken. Qua uniformiteit en werkbaarheid zijn er nog stappen te zetten.
Hoogteverschil
Lastig is dat met de CityJSON import van 3D Basisvoorziening ook nog eens een translate in z-richting (NAP) tevoorschijn komt. Welke reden het Kadaster hiervoor heeft kan ik niet achterhalen. Misschien had Kadaster heel Nederland boven 0.0 NAP nodig om ermee te kunnen rekenen? Deze translatie vraagt in ieder geval wel aandacht.
Wat we al vermoedden blijkt te gaan gebeuren. De topografie van de 3D basisvoorziening komt op een verkeerde locatie terecht ten opzicht van de gebouwen (XY). En in Z-richting ligt de 3D basisvoorziening inderdaad 100 m te hoog t.o.v. NAP. Dit wordt een hachelijke zaak om te repareren.
Het is makkelijker om er twee aparte Revit modellen van te maken. Ieder met aparte verschuivingen en RD en PBP definities. Dus een extra file voor 3D basisvoorziening met verschuiving: 187043438,427603069,-99989,997 (XYZ in mm). De verschuivingen met een exacte afronding in meters nauwkeurig kunnen ook veel ellende voorkomen. Per "tegel" (of bestand) zou dit eenvoudig en duidelijk moeten zijn. Het zou makkelijker zijn dat je niet hoeft te zoeken naar de waarde. Dit soort aspecten kwamen ook aan bod tijdens de gesprekken met data aanbieders tijdens de 3D GeoBim ronde-tafel gesprekken. Hierover volgt later in het voorjaar een rapportage vanuit digiGO (i.s.m. GeoBIMexperts).
De 3D topografie is uiteindelijk in een nieuw Revit bestand geïmporteerd en dan is duidelijk de verkeerde hoogtemaat van de Waalkade te zien. Als controle gebruiken we de AHN viewer. Deze laat zien dat +11.6 wel kan kloppen:
Repareren van de XYZ
Nu ‘repareren’ we de XY én Z weer met methode ‘Shared coordinates’. Als je de hoogtemaatvoering nu op Survey zet, lijkt het goed te gaan met de hoogte. Maar hoe komt Revit met ‘based op Project Base Point’ met +111.5? Daar zal een diepzinnige Revit logica achter schuil gaan.
Hoe dan ook zijn er nu twee modellen voorbereid. Eén file met de gebouw geometrie uit 3D BAG, RD en NAP correct, en een model voor 3D topo. Ook RD en NAP correct. Ze hebben dus allebei een aparte RD-definitie op het interne Revit nulpunt dat gelijk is aan Project BasePoint. Een derde model kan ik nu aanmaken waarin ik deze twee er onder leg en met ‘reference’ samenvoeg voor een totaalbeeld. Voordeel is dan ook dat je nog zelf aan het stuur zit en de verschuiving makkelijk kan bepalen. En blijkbaar ontkom je daar niet aan omdat Revit niet in staat blijkt modellen ten van opzichte van elkaar te positioneren.
Na het verplaatsen van de topografie naar het hoekpunt van het casinogebouw krijgen we het uiteindelijke resultaat. Omdat alle geometrie als ‘generic model’ wordt ingevoegd zie je de triangulatie van de vlakken. Dit zou wel kunnen als Revit type Topografie. ChatGPT geeft me hiervoor een hint. Wat ook opvalt is de toename in grootte van de Revit file. Dit is ook met andere BIM formaten het geval. De CityJSON bestanden gaan veel handiger om met het wegschrijven van bepaalde posities.
Conclusies
- De tool werkt erg goed voor 3D BAG
- Het automatisch toekennen van het RD punt is gewenst
- 3D Basisvoorziening kan geïmporteerd worden met de tool
- De aard en opzet van 3D Basisvoorziening als dataset maken het wel een uitdaging.
- Het kost veel tijd om de data na te bewerken.
Wil je feedback geven? Dat kan! Neem contact met ons op.
