Integratie BIM- en GIS-data

Door Abdoulaye Diakité, Thomas Krijnen, Hugo Ledoux, Ken Arroyo Ohori, Friso Penninga en Jantien Stoter

Met een goede aansluiting tussen BIM- en geodata worden veel toepassingen mogelijk geacht. Zo kan een BIM-model worden ingediend bij een vergunningsaanvraag, waarna een gemeente dit model kan inlezen in een (3D-)geo-omgeving om de impact ervan automatisch te beoordelen. Voorafgaand aan het vergunningstraject kan de ontwerper in zijn (BIM-)ontwerp rekening houden met de bestaande (geo-)omgeving. Vergunningstrajecten worden daarmee veel sneller én objectiever. Andere toepassingen zijn het beheer van een digitale ‘twin’ van de stad op basis van geïntegreerde BIM- en GIS-data en het koppelen van ontwerp- en beheer-data (BIM) met op GIS gebaseerde assetmanagementtoepassingen. Wat is ervoor nodig om deze mooie ideeën te realiseren?

Integratie niet vanzelfsprekend
Al zeker sinds de jaren negentig denkt men na over hergebruik van BIM- (toen nog CAD-)data in GIS-toepassingen, en vice versa. Maar dit hergebruik blijft vooralsnog beperkt tot project-gebaseerd, interactief uitwisselen van elkaars data en informatie. Integratie van GIS- en BIM-data is dan ook niet vanzelfsprekend. De GIS- en de BIM-werelden kennen veel overeenkomsten, maar ook erg veel verschillen wat betreft de manier waarop ze identieke objecten uit de werkelijkheid modelleren, het detailniveau, de software waarmee ze werken en hun open standaarden: City(GML) voor GIS en IFC voor BIM. Door deze verschillen (zie tabel 1), verschillen ook de BIM- en GIS-data fundamenteel van elkaar waardoor hergebruik niet triviaal is.

Semantic Mapping
De oplossingen voor integratie van BIM- en GIS-data, hebben zich tot nu toe vooral gericht op het ‘mappen’ van de semantiek (met succesvolle implementaties zoals de Object Type Library) of het één-op-één converteren van geometrische objecten. Bijvoorbeeld softwaresystemen als Building Information Modelserver, IfcExplorer en Safe FME bieden alle de mogelijkheid om IFC-modellen te converteren naar CityGML. Hierbij worden alle elementen geconverteerd, zonder selectie of nabewerking. Voor visualisatie is dit geen probleem. Maar voor zinvol gebruik van IFC-data in GIS-applicaties moeten ruimtelijke concepten zoals ‘kamers’ (afwezig in IFC-modellen) worden gereconstrueerd door muren (en andere elementen), die in BIM zijn gemodelleerd als volumes, om te zetten naar vlakken die gezamenlijk weer een gesloten volume vormen, zie afbeelding 1. Ook dient er selectie plaats te vinden op de duizenden elementen die doorgaans in een BIM-model zitten (Donkers et al. (2016)).

Wat is het doel?
Integratie van BIM en GIS wordt vaak als oplossing gebracht, maar in de praktijk is dit dus nog niet zo makkelijk. Ervan uitgaande dat de verschillen tussen BIM en GIS een bepaald doel dienen, zijn we in 2017 gestart met een GeoBIM-project om meer inzicht te krijgen in welke BIM-data in de praktijk er nu precies hóe gewenst zijn in de geo-wereld (en andersom) en hoe we voor deze conversies (IFC <-> CityGML) een open oplossing kunnen ontwikkelen om de al zo lang gewenste integratie verder te helpen. Het project is geïnitieerd door Geonovum en is een samenwerking met BIM Loket en een aantal belangrijke gebruikers (Rijkswaterstaat, Kadaster, de gemeenten Rotterdam en Den Haag). Het onderzoek is uitgevoerd door onderzoeksgroepen uit de twee respectievelijke werelden: 3D Geo-informatie TU Delft en BIM TU Eindhoven.

Geometrieverschillen tussen CityGML en IFC
Ons project richtte zich op het omzetten van geometrie, omdat de geometrie nodig is bij hergebruik van data en de integratie van IFC- en (City)GML-geometrie nauwelijks nog aandacht heeft gehad. CityGML bevat twaalf modules voor verschillende typen objecten zoals gebouwen, bruggen en water. Deze kennen alle een expliciete geometrie-beschrijving in 3D. Dat wil zeggen dat de geometrie wordt beschreven aan de hand van begrenzingen vastgelegd met coördinaten. IFC-bestanden kennen veel meer klassen (meer dan 1000). Bovendien wordt de geometrie bijna zelden beschreven via een expliciete beschrijving van de begrenzing, maar veel vaker door zogenaamde ‘impliciete’ geometrie. Dat wil zeggen dat via operaties de geometrie kan worden verkregen. Een object wordt bijvoorbeeld beschreven aan de hand van voor-gedefinieerde parametrische profielen, zie afbeelding 2.

Andere impliciete geometrieën in IFC worden beschreven door middel van Constructive Solid Geometry (CSG)-modellering, waarbij een volume-object wordt gedefinieerd als een serie van boolean-bewerkingen (‘union’, ‘intersection’, difference’) op simpele volume-objecten zoals een bol of een kegel. Of een geometrie wordt beschreven via Sweep Volumes, waarbij een volume wordt gereconstrueerd door een 2D-dwarsdoorsnede uit te trekken langs een bepaald profiel.

De conversiemethode
In ons project richtten we ons op gebouwen en waren er drie IFC-modellen beschikbaar van ontwerpen in de gemeente Den Haag met enkele duizenden (!) elementen per bestand, zie afbeelding 3. De conversie is ontwikkeld met behulp van IfcOpenShell en CGAL, de opensoftware-bibliotheken van IFC, respectievelijk geo-data. In onze conversie worden alle relevante (volumetrische) elementen uit de IFC-bestanden geconverteerd naar CityGML-klassen met bijbehorende geometrie. Relevant betekent hier alle elementen die volgens de IFC-standaard een ‘belangrijk functioneel onderdeel van een gebouw vormen’. Dit zijn: IfcBeam, IfcBuildingElementComponent, IfcBuildingElementProxy, IfcChimney, IfcColumn, IfcCovering, IfcCurtainWall, IfcDoor, IfcFooting, IfcMember, IfcPile, IfcPlate, IfcRailing, IfcRamp, IfcRampFlight, IfcRoof, IfcShadingDevice, IfcSlab, IfcStair, IfcStairFlight, IfcWall, IfcWindow. Een belangrijke stap in deze conversie is het vertalen van de impliciete, parametrisch beschreven geometrieën naar polyhedrons met expliciete geometrie. Hierbij wordt een groot aantal (kleine) polygonen gegenereerd voor optimale benadering van de bedoelde geometrie. Bij het omzetten van de CSG-representaties worden hierna ook nog de boolean-bewerkingen uitgevoerd.

Resultaten
Visueel kwam hier een aardig resultaat uit. Maar helaas bevatten de oorspronkelijke IFC-bestanden zo veel fouten (meer dan 150 per IFC-bestand) dat het onmogelijk bleek om foutloze GIS-geometrieën te genereren die nodig zijn voor ruimtelijke analyses. Vaak was de conversie überhaupt onmogelijk vanwege deze niet-valide objecten.

Let wel: dit zijn veelal fouten vanuit een GIS-perspectief; ze vormen voor BIM’ers, voor zover zij geen structurele analyses uitvoeren, geen probleem. Ten eerste omdat de meeste BIM-software met deze ‘fouten’ overweg kan: het worden vaak pas fouten wanneer de impliciete geometrieën worden omgezet naar expliciete geometrieën. En ten tweede omdat BIM-modelleurs er bij hun ontwerpen op gericht zijn om een digitaal plan te maken en niet om een bestand te maken ten behoeve van ruimtelijke analyses, waardoor de gevonden ‘fouten’ niet als zodanig worden ervaren. Hier stuitten we dus op fundamentele verschillen tussen BIM en GIS die aandacht behoeven bij toekomstige ontwikkelingen rond BIM- en GIS-data-integratie. 

Meest voorkomende fouten
De meest voorkomende (GIS-)fouten in de IFC-bestanden waren niet-platte vlakken, zelf-intersectie en intersecties tussen twee verschillende elementen. Vooral de zelf-intersecties zijn interessant (zie afbeelding 4), want de IFC-standaard verbiedt dit expliciet. Blijkbaar wordt hier niet op gecontroleerd door de BIM-software. Een verdere bewerking van de geometrieën (zoals in afbeelding 1) is alleen mogelijk met correcte geometrieën. Daarom hebben we voor een groot deel van deze fouten een detectie- en reparatie-oplossing ontwikkeld. Een oplossing voor alle mogelijke fouten voor de ook nog eens tientallen mogelijke IFC-geometrie-typen was echter niet realistisch binnen dit project. Hierdoor kon een automatische conversie van IFC naar een in GIS-software bruikbaar bestand, helaas niet worden gerealiseerd.

Een ander probleem waardoor een automatische conversie veel moeilijker te ontwikkelen bleek dan verwacht, is dat IFC zo veel klassen kent en er geen of nauwelijks validatie-tools zijn, waardoor in de praktijk IFC-modellen erg gevarieerd kunnen zijn voor identieke situaties, zelfs binnen eenzelfde bestand. Een conversie die met al deze mogelijkheden rekening houdt, is onmogelijk om te ontwikkelen (of alleen voor grote bedrijven). We moesten dan ook concluderen dat een conversie van ‘ideale’ IFC-modellen weliswaar mogelijk is. Dat is ook ruimschoots onderzocht in de wetenschap. Maar door de in de praktijk aanwezige ‘fouten’ in IFC-modellen en de grote variatie in IFC-modellering is een automatische conversie naar CityGML ten behoeve van ruimtelijke analyses met huidige IFC-modellen onmogelijk.

Richtlijnen
In plaats van nog meer tijd te investeren in het detecteren en repareren van nog meer fouten voor nog meer mogelijke IFC-alternatieven, leek het ons daarom beter om richtlijnen te formuleren voor het modelleren van IFC-data, zodat de automatische conversie naar GIS-data mogelijk wordt. Hierbij hebben we alleen gekeken naar de conversie van IFC naar (City)GML. Uiteraard dient ook gekeken te worden naar hoe GIS-data kunnen worden geprepareerd, zodat deze ook toegankelijk zijn voor BIM-toepassingen. Denk bijvoorbeeld aan de geologische ondergrond in een BIM-formaat (Diakité en Stoter, 2017). Deze richtlijnen zouden kunnen worden gebruikt als strikte eisen ten behoeve van specifieke use-cases, zoals die van een vergunningsverleningtraject, tot meer algemene richtlijnen die op nationaal of zelfs internationaal niveau zouden moeten gelden voor alle IFC-bestanden om een betere integratie tussen de BIM- en geo-wereld mogelijk te maken.

Richtlijn: een juist gebruik van IFC
De eerste voor de hand liggende richtlijn voor IFC-modellering ten behoeve van GIS is om de beschikbare voorschriften voor een juist gebruik van IFC strikt te volgen en om BIM-software deze richtlijnen te laten ondersteunen. De IFC-standaard, maar ook aanvullende implementatierichtlijnen voorgeschreven door de internationale standaardisatie-organisatie buildingSMART, en externe richtlijnen zoals de in Nederland vastgelegde BIM basis Informatieleveringspecificatie (BIM basis ILS, 2017)) schrijven voor welke IFC-klassen wanneer dienen te worden gebruikt, mogelijke attribuutwaarden, en het vermijden van redundante of snijdende objecten. Helaas worden deze richtlijnen in de praktijk niet altijd gevolgd, waardoor er eigenlijk geen sprake is van gestandaardiseerde IFC-data die voldoen aan deze voor automatische conversie benodigde richtlijnen. 

Richtlijn: georefereren
Een andere belangrijke benodigde richtlijn betreft het georefereren van IFC-data op een manier die begrijpelijk is voor BIM’ers. Hoewel georefereren een fundamentele eis is om IFC-data überhaupt in GIS te kunnen gebruiken, blijkt in de praktijk het georefereren van BIM-data verre van vanzelfsprekend. In theorie kunnen latitude en longitude worden aangegeven in het IFC-bestand met een offset ten opzichte van het noorden. Echter, in de praktijk worden deze waarden vaak op ‘0’ gezet, of ze verwijzen naar een compleet foute (waarschijnlijk een default) locatie of naar een ‘ongeveer’ locatie (een punt in de betreffende stad). Ook de IFC-bestanden van Den Haag bevonden zich geen van alle op de juiste positie. Het georefereren wordt nog eens gecompliceerd doordat verschillende versies van IFC verschillende notatiewijzen hebben voor de longitude: een positieve waarde staat in IFC2x3 ten oosten van de 0-meridiaan en in IFC4 ten westen van de 0-meridiaan. Voor architecten heeft het georefereren, vanwege hun lokale focus, niet altijd nut. Vandaar dat het bewust maken bij architecten van de waarde hiervan een belangrijk onderdeel van de oplossing is, geholpen door tools. Zo hebben we een web-service ontwikkeld die een IFC-model inleest en deze vervolgens toont op de in de IFC vastgelegde locatie. De gebruiker kan dan zien waar zijn IFC-bestand wordt gepositioneerd. Indien deze locatie incorrect is, kan de gebruiker de juiste locatie aangeven, waarna de coördinaten-informatie in het IFC-bestand wordt overschreven.

Formele afspraken over modelleerwijzen
Andere richtlijnen die we aanbevelen zijn voor het genereren van geometrisch valide objecten (en het afdwingen ervan in bijbehorende validatie-tools) en het modelleren van concepten die voor een architect niet, maar voor ruimtelijke analyses wél van belang zijn en die achteraf erg lastig te reconstrueren zijn, zoals een (correcte) geometrische representatie van ‘ruimtes’ (kamers, hallen en trappenhuizen). Een laatste richtlijn die we voorstellen vanuit dit project is om formele afspraken te maken hoe specifieke situaties moeten worden gemodelleerd met IFC. Zelfs binnen eenzelfde bestand kwamen we verschillen tegen voor soortgelijke situaties. Bovendien raden wij aan om hierbij de generieke klasse IfcBuildingElementProxy (die veelvuldig lijkt te worden gebruikt) te vermijden, maar in plaats daarvan een van de talrijke specifieke klassen te gebruiken, bij voorkeur een klasse die direct kan worden gemapt met een CityGML-klasse (zoals IfcSlab).

Drie voorbeelden van fouten die in de IFC-bestanden werden aangetroffen.

Tot slot
Integratie van BIM en GIS biedt, zoals veel onderzoeken, pilots en showcases al hebben laten zien, veel mogelijkheden. Maar werkend met IFC-modellen uit de praktijk, blijkt dat de integratie nog niet zo makkelijk is. We hebben met dit project laten zien dat een eenduidige én specifieke modellering van IFC (met de bijbehorende validatie-tools) nodig is om een automatische conversie van de gedetailleerde BIM-data, bestaande uit een groot aantal elementen, naar geaggregeerde objecten, geschikt voor GIS-analyses, én weer terug, überhaupt mogelijk te maken. Pas dan worden de talrijke potentiële toepassingen van BIM-geo-integratie haalbaar. Het maken van afspraken hiervoor, deze vastleggen in open standaarden en het strikt volgen van deze standaarden is een belangrijke vervolgstap.