Ga door naar hoofdcontent
ArtikelenGebruik van BIM in Geo in de praktijk: voorbij de hype

Gebruik van BIM in Geo in de praktijk: voorbij de hype

Woensdag 1 april 2020Afbeelding Gebruik van BIM in Geo in de praktijk: voorbij de hype

Gedetailleerde modellen van gebouwen (BIM) worden als waardevol gezien in combinatie met geo-data. Met behulp van virtuele modellen van nieuwe gebouwen (of delen ervan) kan de impact van scenario’s worden doorgerekend op bijvoorbeeld energie, geluid of wind. Al tijdens de ontwerpfase kan rekening worden gehouden met planologische beperkingen, als deze informatie beschikbaar is. Het BIM kan na oplevering van het bouwwerk worden gebruikt als gebouwgebonden informatiedossier voor domeinen als energie, circulaire economie enzovoorts..

De mogelijkheden van GeoBIM lijken eindeloos; maar wat is de waarde ervan in de praktijk voorbij de hype? Dat is een vraag die ons inspireert bij onze GeoBIM onderzoeksprojecten (zie referenties) en die centraal staat in dit artikel.

Cruciaal zijn de open standaarden die uitwisseling van geo- en BIM-data buiten individuele, specifieke software-omgevingen mogelijk maken. Daarbij kijken we met name naar IFC (voor BIM, zie kader) en CityGML (voor geo). Er zijn meerdere geo- en BIM-standaarden (LandInfra/InfraGML, gbXML). Maar CityGML en IFC worden het meeste gebruikt in de praktijk. Bovendien zijn deze standaarden (en daarmee onze bevindingen) representatief voor fundamentele karakteristieken in de beide domeinen.

Objecten in BIM en geo zijn niet hetzelfde

In de geo-wereld bedoelen we met BIM bijna altijd het zeer gedetailleerd ontwerp van een bouwwerk dat wordt beschreven aan de hand van de elementen waaruit het bouwwerk bestaat. BIM- en geo-modellen hebben een groot aantal verschillen. Hierdoor is hergebruik in de praktijk minder triviaal dan in pilots vaak wordt gesuggereerd, waar de structuur en inhoud van de data kan worden gecontroleerd. Zo wordt geometrie in geo-applicaties doorgaans ingewonnen (gemeten) en in BIM ontworpen op basis van parametrische primitieven in relatie tot andere objecten (figuur 1). Zolang je in een specifieke softwareomgeving blijft, ondersteunt deze parametrische beschrijving vele mogelijke vormen. Bovendien zijn objecten en hun relaties automatisch valide en consistent te houden bij wijzigingen. Dit is de kracht van BIM-software. Maar voor het gebruik van BIM-objecten in een geo-omgeving moeten de parametrische beschrijvingen worden omgezet naar expliciete geometrieën: geometrische elementen gedefinieerd als een schil van coördinaten (de zogenaamde boundary representatie). Dit maakt conversie naar andere formaten moeilijk. Daarnaast is de benodigde ‘discretisation’ gevoelig voor fouten.

Een ander groot verschil is het schaalniveau. Voor geo-applicaties is het voldoende om gebouwen te modelleren als entiteiten, met 3D vlakken (muren) als geometrische begrenzingen, en eventueel verblijfsruimten hierin. Een groter detailniveau is zelfs vaak onwenselijk. Een BIM daarentegen bevat een groot aantal (vaak honderden of duizenden) elementen die tezamen een bouwwerk vormen. Deze elementen, hoe klein ook, zijn volumetrisch beschreven, denk bijvoorbeeld aan een deurklink of een kitvoeg. Voor zinvol gebruik van BIM-data in geo-applicaties moeten relevante geo-concepten worden gegeneraliseerd uit de BIM-data, zoals de buitenkant van een gebouw. Het versnijden van alle individuele volumes om tot een uniforme buitenkant te komen is rekenkundig erg intensief en bovendien zijn er door afrondingsfouten, modelleerfouten of bouwkundige principes (ventilatie, dilatatie) vaak smalle ruimten tussen de elementen waardoor het samenvoegen van de elementen geen goed resultaat geeft.

Een laatste fundamenteel verschil is het gebruik van een lokaal coördinatenstelsel in BIM versus het gebruik van een geografisch coördinatenstelsel in geo. Dit kan worden opgelost door de BIMs te georefereren, maar dat is in de praktijk nog geen gemeengoed. Bovendien kunnen bouwwerken die een groot gebied omvatten en gedefinieerd in een cartesisch coördinatenstelsel ongewenste vertekeningen krijgen als ze worden omgezet naar een geografisch coördinatenstelsel.

Hoe zien IFC-modellen er in de praktijk uit?

Onderzoeken en pilots hebben laten zien dat IFC-modellen bruikbaar zijn in het geo-domein. Maar vaak gaat dit om academisch vervaardigde IFC-modellen met een gecontroleerde structuur en content. Om te kijken hoe IFC in de praktijk wordt gebruikt en wat we hiervan kunnen hergebruiken in het geo-domein, hebben we 37 IFC-modellen nader bekeken.

Gebruikte software en versie van de standaard

Het merendeel van de modellen is gegenereerd in Autodesk Revit. Op een na, zijn de IFC-modellen in IFC2x3 gemodelleerd (vastgesteld in 2005 en voor de laatste keer gewijzigd in 2007); ook al is IFC4 sinds 2013 vastgesteld. Het enige model dat in versie 4 werd aangeleverd, was op ons verzoek naar deze versie geëxporteerd. Dat de laatste vigerende versie van IFC in praktijk nauwelijks wordt gebruikt kan duiden op lage urgentie van het gebruik van open standaarden en/of ingewikkelde implementatie van ondersteuning van de standaard.

Gebruikte semantiek

Voor de interoperabiliteit met andere (geo) formaten zijn twee elementen van specifiek belang: IfcOpening en IfcSpace. IfcOpening wordt gebruikt om een deel van een ander object af te trekken voor een andere geometrie zoals een IfcWall of een IfcSlab om consistentie tussen gat (IfcOpening) en bijbehorend deel-object (IfcDoor, IfcWindow) te garanderen. In de meeste modellen blijkt deze informatie correct aanwezig. De klasse IfcSpace kan worden gebruikt om lege ruimtes te definiëren, zoals kamers en hier attributen aan toe te kennen zoals nodig in geo-applicaties. Deze informatie is tijdens de bouwfase vaak niet nodig, maar wel in downstream applicaties. In 16 van de modellen werd dit concept gebruikt.

Een ander relevant IFC-concept voor hergebruik van de data is het IfcBuildingElementProxy element. Dit concept kan worden gebruikt voor klassen die niet worden ondersteund in IFC. Maar in praktijk (in bijna 90% van de modellen) blijkt dit element gebruikt voor elementen waarvoor wel een geschikte (specifieke) IFCklasse beschikbaar is, zoals IfcBeam, IfcBuildingElementPart, IfcCovering, IfcCurtainWall, IfcDoor, IfcFooting, IfcRailing, IfcRamp, IfcRamp- Flight, IfcRoof, IfcSlab, IfcStair, IfcStairFlight, IfcWall, IfcWindow. Door het veelvuldig gebruik van de generieke klasse, gaat veel semantiek verloren die niet kan worden gebruikt in downstream toepassingen of bij transformaties naar andere domeinen (zoals geo).

Georefereren

In IFC kun je geografische coördinaten van een referentiepunt (met beperkte precisie) opslaan bij het object IfcSite in WGS84 (EPSG: 4326) of meer specifiek via het toevoegen van een IfcCartesianPoint aan IfcSite. Op deze manier kan het model in de werkelijkheid worden gelokaliseerd, nodig voor de GeoBIM integratie. In IFC4 is het ook mogelijk meer complexe informatie op te slaan, zoals CRS, projectie en parameters.

Een derde van de IFC-modellen bevat gedetailleerde georeferentie informatie waarvan twee modellen ook informatie bevatten over ‘True North’ (roteren van de ‘True North’ richting blijkt overigens alleen mogelijk in BIMsoftware). Een derde van de modellen bevat globale referentie-informatie en een derde van de modellen een lokaal coördinatensysteem. Omdat BIM-software georeferentie-informatie automatisch kan toevoegen aan de modellen (bijvoorbeeld nadat de gebruiker een adres invoert), konden we niet goed achterhalen welke modellen bewust geogerefereerd waren door de ontwerpers.

Een probleem bij het georefereren, is het verschil van notatie tussen IFC2x3 en IFC4. De breedtegraad en lengtegraad worden gedefinieerd als hoeken met graden, minuten, seconden ten opzichte van het geodetische WGS84. Positieve waarden beschrijven locaties ten noorden van de evenaar, en ten westen van de geodetische nulmeridiaan (nominaal de nulmeridiaan van Greenwich) in IFC2x3, of ten oosten van de nulmeridiaan in IFC4. Negatieve waarden beschrijven locaties ten zuiden van de evenaar, en ten oosten van de nulmeridiaan in IFC2x3 of ten westen van de nulmeridiaan in IFC4. De inconsistentie tussen verschillende versies van IFC is uiteraard gevoelig voor fouten. Dit gaat vooral spelen als er meer modellen in versie 4 beschikbaar komen.

IFC

 

De standaard IFC, vastgesteld door buildingSMART, bevat meer dan duizend klassen voor alle informatie en concepten nodig bij het gebruik van gebouw-elementen in het AEC-FM domein voor alle mogelijke use cases. De huidige focus van IFC is gebouwen. Er wordt momenteel gewerkt aan een IFC-uitbreiding voor infrastructuur.

 

De Information Delivery Manual (IDM, informatie levering-specificatie) is complementair aan IFC en ook uitgegeven door buildingSMART. Het definieert de workflow en informatie-uitwisseling specificaties die nodig zijn voor een specifiek doel. Binnen IDMs kunnen er Model View Definitions (MVD) gespecificeerd worden die de randvoorwaarden aan een IFC-model vastlegt om de procedures en informatiebehoeften beschreven in het IDM te volgen. MVDs kunnen heel specifiek en selectief zijn (om een bepaald gordijn-muur systeem te beprijzen) maar ook zo breed als het gehele IFC-schema (om bijvoorbeeld het gehele project te archiveren). Voor software ondersteuning voor IFC, worden in de praktijk de MVDs geïmplementeerd om data vanuit een native softwareformaat te exporteren naar de in de MVD-beschreven selectie van IFC. Het gaat dan vaak om een selectie van het gehele BIM ten behoeve van een specifieke toepassing. Het complete en origineel van de data over een bouwwerk is daarmee alleen beschikbaar in de software-omgeving waarin het model is gemaakt. Binnen een bepaald softwaresysteem wordt het principe van één basismodel ondersteund: met BIM-ontwerptools kun je verschillende (selectie)views uit een bouwmodel maken voor bijvoorbeeld het plannen van de bouw of het berekenen van de stevigheid van de constructie. Deze verschillende weergaven zijn automatisch consistent en gebaseerd op dezelfde object-instanties.

Omzetten van IFC naar CityGML en vice versa

Voor hergebruik van BIM-data in geoapplicaties, en andersom zijn conversies nodig. We hebben gewerkt aan de conversie van IFC naar CityGML-LoD3 (een model met dakvormen, deuren en ramen). Deze conversie maakt het bijvoorbeeld mogelijk om een BIM te gebruiken voor het updaten van een 3D stadsmodel of in een geo-analyse. Eerdere oplossingen converteerden alle IFC-elementen naar CityGML. In onze aanpak daarentegen zijn een aantal geometrische bewerkingen ontwikkeld om de IFC-elementen te versimpelen en aggregeren, waarna de resterende elementen een valide en werkbare LoD3 opleveren, begrensd door vlakken, zie figuur 2.

Een probleem bij het ontwikkelen van een robuuste conversie is – naast het omzetten van parametrische beschrijvingen naar expliciete geometrie – het grote aantal geometrische klassen van IFC. Het ontwikkelen van een conversiemethode die alle mogelijke klassen ondersteunt, is niet haalbaar. Afspraken maken over de te gebruiken geometrieën, en een zo specifiek mogelijke semantiek, is daarom een voorwaarde voor een succesvolle conversiemethode.

Merk op dat degene die een BIM beschikbaar stelt in IFC in de meeste gevallen geen invloed heeft op de inhoud en kwaliteit van het geëxporteerde IFC-model. Er wordt vaak gebruik gemaakt van een standaard expert-functionaliteit die een black box is voor gebruikers. In een MSc onderzoek hebben we onlangs ook de conversie andersom ontwikkeld: van CityGML naar IFC om bijvoorbeeld een 3D stadsmodel in te laden in BIM-software. De methode voegt ook een referentiepunt toe met de georeferentie informatie uit het oorspronkelijke CityGML bestand.

Casestudie in de praktijk

Om meer inzicht te krijgen in hoe veronderstelde GeoBIM potenties in de praktijk werken, staat het proces voor de verlening van een bouwvergunning – een veelvuldig genoemde use case voor GeoBIM – centraal in ons onderzoek.

Behalve enkele pionierende experimenten worden in het huidige vergunningsverleningsproces in Nederland (net als in alle landen van onze samenwerkingen) PDF’s, of zelfs papieren tekeningen ingediend. Deze zijn vaak wel gegenereerd uit een digitaal ontwerp maar niet in een geo-omgeving in te lezen. De PDF’s worden interactief beoordeeld door de toetser bij de gemeente, waarbij – door tijdgebrek – vaak alleen op de meest significante regels wordt gecontroleerd. Bovendien bestaan er geen tools om metrische aspecten in PDF’s te checken.

Daarom wordt bij de beoordeling vertrouwd op wat er in de tekeningen (afstanden, dimensies) en in de bijbehorende rapporten (zoals energie-performance, gebouwfysica berekeningen) wordt aangegeven.

In een GeoBIM aanpak, kan een ingediend BIM deels geautomatiseerd en op veel meer aspecten worden gecontroleerd, zodat de toetser een meer volledige en waarheidsgetrouwe controle kan doen. Bovendien wordt het proces objectiever, omdat het gebruik van data in (semi) automatische controles afdwingt om mogelijk interpretaties van regels te standaardiseren. Een (simpele) regel over maximale bouwhoogte stuit al op vragen zoals: welke nauwkeurigheidsbandbreedte hanteren we als we het BIM (mm-niveau) met de geo-omgeving (dm/m-niveau) confronteren? En hoe bepalen we de bouwhoogte van een BIM, welke elementen nemen we daarbij mee en wat hanteren we als nulpunt? In de praktijk gaat het om veel complexere regels waar vaak verschillende regels tegen elkaar afgewogen moeten worden. Om dit beter te begrijpen, hebben we in een samenwerking met de toetsers van de gemeente Rotterdam een aantal relevante regels geselecteerd uit het bestemmingsplan van het Maritiem District:

5.2.3 Bebouwingsnormen

  • a. De maximum bouwhoogte is 100 meter, met dien verstande dat deze gerealiseerd mag worden met een onderbouw van maximaal 17 meter hoog en een opbouw van maximaal 50% van de oppervlakte van de onderbouw;
  • b. Ter plaatse van de Boompjes 60-68 en de Boompjes 55-58 is boven de 17 meter een overkraging toegestaan van 5 meter aan de Boompjeszijde en 10 meter aan de zijde van de Hertekade.

Voor de testcase gebruiken we het IFC-model van een nieuw ontworpen gebouw (zie figuur 3).

Het vertalen van de regels naar een GeoBIM implementatie kan als volgt (voorbeelden zijn schematisch weergegeven in de figuren):

1. Voor regels voor onderbouw, opbouw en overkragingen moet het gebouw worden opgedeeld in geometrisch-relevante delen op basis van ‘uitstulpingen’ en footprints hiervan, zie figuur 4.
2. Voor de maximale hoogtebepaling is de intersectie met het terrein nodig (figuur 5).
3. Vervolgens kan de hoogte van de onderbouw worden bepaald (figuur 6, links) en de intersectie (oppervlakte) tussen onderbouw en opbouw (zie figuur 6, rechts).
4. Tenslotte, voor de overkragingen van de delen boven de 17 meter die zijn toegestaan aan beide zijden (5 meter respectievelijk 10 meter), moeten de ‘uitstulpende’ gebouwdelen worden bepaald, zie figuur 7.

Op dit moment ontwikkelen we de algoritmes om de benodigde (geometrische) informatie uit het BIM te genereren. De gegenereerde objecten kunnen ook gebruikt worden voor andere toepassingen zoals verblijfseenheden in de 3D BAG of het gebouwgebonden informatiedossier.

Tot slot

Het geïntegreerde gebruik van geo- en BIMdata biedt potenties. Deze potenties kunnen worden benut in de praktijk als technische oplossingen en standaarden de verschillen tussen de geo- en BIM- domeinen adresseren, zoals verschillen in geometriebeschrijvingen, in semantiek en verschillen in detailniveau. Daarnaast is het belangrijk om te begrijpen hoe BIM-data meerwaarde kan bieden in geo-applicaties en andersom zodat relevante concepten kunnen worden afgeleid voor hergebruik. Hierbij moeten ook alle versies van de modellen actueel en synchroon worden gehouden zoals de ‘as built’ versus ‘as designed’ en het gedetailleerde BIM met de gegeneraliseerde geo-versie. Een belangrijke les die wij hebben geleerd van de toetsers, is dat er voor sommige workflows altijd menselijke kennis en kunde nodig zal zijn om de data en analyses te interpreteren. De waarde van een GeoBIM aanpak is dan niet de volledige automatisatie, maar dat de data het mogelijk maakt om het proces objectiever, meer waarheidsgetrouw en sneller (en dus beter) te maken.

De projecten genoemd in dit artikel ontvingen financiering van de European Research Council (ERC) onder het ‘European Union’s Horizon 2020 research and innovation programme’ (Grant agreement No 677312 UMnD en Marie Skłodowska-Curie grant agreement No 707404).

Referenties

  • Noardo, C. C. Ellul, L. Harrie, I. Overland, M. Shariat, K. Arroyo Ohori, J. Stoter. 2019, Opportunities and challenges for Geo- BIM in Europe: developing a building permits use-case to raise awareness and examine technical interoperability challenges. Journal of Spatial Science
  • Noardo, F. F. Biljecki, G. Agugiaro, K. Arroyo Ohori, C. Ellul, L. Harrie, J. Stoter GeoBIM Benchmark 2019: Intermediate Results. ISPRS – International Archives, pp. 47–52
  • European Network for Digital Building Permits, 3d.bk.tudelft.nl/ projects/eunet_bp/
  • Rotterdam GeoBIM project for building permission, 3d.bk.tudelft.nl/projects/rotterdamgeobim_bp/
  • Nebras, S., 2019, Automatic Conversion of CityGML to IFC, MSc thesis, https://3d.bk.tudelft.nl/education/#theses
  • Donkers, S., H. Ledoux, J. Zhao and J. Stoter, 2015, Automatic conversion of IFC datasets to geometrically and semantically correct CityGML LOD3 buildings, Transactions in GIS
  • Arroyo Ohori, K, A. Diakité, T. Krijnen, H. Ledoux and J. Stoter, 2018, Processing BIM and GIS models in practice: experiences and recommendations from a GeoBIM project in the Netherlands. ISPRS International Journal of Geo-Information 7(8)