De bestanden komen op elk project op dezelfde manier binnen. Eén IFC van de architect, één van de constructeur, één van de installateur, elk getekend in een ander programma. U opent ze, en de helft van de tijd vallen ze niet op hun plek, of blijkt een wand een naamloos blok zonder iets erachter. De reflex is de viewer de schuld te geven. Meestal ligt het aan de export. Dit is wat een schoon IFC-bestand draagt, uit welke tool het ook komt, en hoe de drie samenkomen in één model.
De tool telt minder dan de instellingen. Dat is het deel dat de meesten overslaan.
De export bepaalt alles
Revit, Archicad en Tekla tekenen elk in hun eigen formaat, en elk exporteert naar IFC. Die export is een vertaling, en zoals elke vertaling kan hij met zorg of in haast gebeuren. Hetzelfde gebouw verlaat het ene bureau als een rijk, bevraagbaar IFC-bestand en het andere als een geometrische huls die er goed uitziet en niets antwoordt. Het programma veranderde niet. De instellingen wel.
De eerste zet is dus niet op zoek gaan naar een betere tool. Het is afspreken, voordat iemand exporteert, wat het IFC-bestand moet bevatten.
Drie dingen die een schone export draagt
Objecten die weten wat ze zijn. Een wand hoort als IfcWall te exporteren, een deur als IfcDoor, een ligger als IfcBeam. Klopt de mapping niet of ontbreekt hij, dan valt alles terug op een generieke IfcBuildingElementProxy: een vorm zonder type. Een proxy is een blok dat u niet kunt filteren, niet kunt tellen en waar u geen regel aan kunt hangen. De objectmapping goed krijgen is het grootste deel van het werk.
De data, niet alleen de vorm. De waarde van een model zit in de property sets en de base quantities: de brandwerendheid, de U-waarde, het materiaal, de oppervlakte en het volume. Een model dat zonder die gegevens is geëxporteerd, is een plaatje. Laat de property sets meekomen, en elk element kan een vraag beantwoorden.
Eén gedeelde oorsprong. Drie bestanden vallen alleen op hun plek als ze het eens zijn over waar het gebouw staat. Stel een gedeeld coördinatenstelsel in, of een gemeenschappelijk nulpunt, vóór de export. Slaat u dat over, dan zweeft de constructie honderd meter van de architectuur, en geen enkele viewer kan de verschuiving voor u raden.
Kies een schema, en zeg welke
IFC bestaat in versies. IFC2x3 is het oude werkpaard, nog overal in gebruik. IFC4 is rijker en inmiddels de gangbare keuze. IFC 4.3, door ISO bekrachtigd als ISO 16739-1:2024, verbreedde het formaat naar infrastructuur. Elk van die versies kan een goed gebouwmodel dragen. Wat problemen geeft, is niet weten welke u kreeg, dus benoem het schema in uw exportafspraak en houd het gelijk over de disciplines. De meeste tools laten u ook een gedefinieerde weergave exporteren, de coordination view, gemaakt voor precies dit: een model doorgeven aan een ander om samen te voegen.
Waar imports misgaan
De meeste importellende komt terug op een handvol exportgewoontes.
De usual suspects
- Alles komt binnen als een proxy, omdat de objecttypes nooit gemapt zijn.
- Elementen zijn aanwezig maar leeg, omdat de property sets zijn weggelaten.
- Volumes lezen duizend keer te groot of te klein, omdat het ene model in millimeters stond en het andere in meters.
- De disciplines overlappen niet, omdat niemand een gedeelde oorsprong instelde.
Geen van deze zijn viewerfouten. Het zijn beslissingen die bij de export zijn genomen, en dat betekent dat ze bij de export te herstellen zijn, zodra u weet waar u moet kijken.
Veel tools, één scene
Hier zit de winst van het goed doen. Omdat IFC van geen enkele leverancier is, en een neutrale organisatie, buildingSMART, de standaard beheert, opent een model uit het ene programma schoon in het andere. Krijg de exports schoon en het model van de architect, dat van de constructeur en dat van de installateur vallen samen in één gefedereerde scene, waar u de leiding door de ligger ziet lopen voordat het beton wordt gestort. Dat is geen Nederlandse truc. Het is dezelfde open standaard, van Rotterdam tot overal in Europa waar het formaat reikt.
Schone data betaalt zich later terug
Hoe schoner het IFC-bestand, hoe meer u er verderop mee kunt. Een bevinding prikt zich aan een echt element in plaats van aan een vage notitie. Een toetsingsregel heeft eigenschappen om te lezen in plaats van lege velden. Het werk dat u in de export steekt, komt terug elke keer dat iemand het model iets vraagt.
Waar wij binnenkomen
Dat gefedereerde model is waar BimDossier begint. Het leest standaard IFC, inclusief het gecomprimeerde .ifcZIP, detecteert het schema bij de upload, en laadt modellen uit elke discipline in één viewer-scene met storey-isolatie en sectievlakken. Prik een bevinding aan een element en hij hangt aan de eigen identificatie van dat element, met een foto en een eigenaar. De compliance-engine draait zijn rulepacks over diezelfde IFC-data.
Wat het niet doet, is het model tekenen. Dat gebeurt nog steeds in Revit, Archicad of Tekla, en een dunne export blijft een dunne export. Krijg het IFC-bestand schoon op de weg naar buiten, en alles wat u erop bouwt, de snags, de certificaten, het Wkb-dossier, zit op een model dat voor zichzelf kan antwoorden.