BIM: IFC brutto e cattivo

Best practice sull’utilizzo del formato aperto IFC esportato da Revit

Da qualche tempo rimandiamo il buon proposito di scrivere qualche pensiero, guida incompleta, best practice non esaustiva sull’utilizzo di IFC esportato da Revit. Quando abbiamo cominciato a interessarci a questo argomento non esistevano “spiegoni” in italiano: qui proviamo a fornirne uno, seppur parziale, ma che elenca le maggiori questioni che abbiamo affrontato qui in Lombardini22.

Recentemente ci siamo anche trovati (>>> per approfondire CLICCA QUI) con alcuni amici del BimUserGroupItaly (#BUGItaly), per dei confronti su questi temi, dove noi di Lombardini22 abbiamo raccontato alcune delle cose contenute in questo articolo.

Si è spesso sentito parlare molto male di IFC, questo è dovuto a molte ragioni, alcune delle quali psicologiche:

• in primis, chi usa in maniera approfondita un software spesso e volentieri vorrebbe anche cucinarci la colazione; è una propensione naturale nell’utilizzare uno strumento che si conosce bene, un po’ per fare qualsiasi cosa; questo è però dannoso perché limita la possibilità di trovare un workflow migliore, più semplice, o più ottimizzato;
• risulta spesso difficile trasferire alcune proprietà dai modelli verso IFC;
• IFC, formato aperto, risulta essere molto “chiuso” verso alcuni utilizzi; si pensi banalmente alla sua modifica, tant'è che si è consolidata un'idea, per la quale sia un formato di consegna non modificabile; questi limiti fanno sì che alcuni finiscano per ritenerlo un formato poco valido tout-court (questo tema da solo meriterebbe una riflessione a parte);

Revit verso lo standard  IFC

IFC nasce con l’obiettivo di garantire la comunicabilità dei dati tramite soggetti che potenzialmente potrebbero usare piattaforme di Authoring diverse, di diverse case software, e con operatori che potrebbero aver bisogno di interrogare questi database per i più svariati fini.

La logica è sempre “ad oggetti”, dove ad un oggetto sono legati dei valori che riempiono campi, in linea teorica, “Standard”.

Il problema è che ogni volta che si sente la parola “Standard” bisognerebbe andare a vedere fino a che punto lo standard è stato recepito da chi lo può scrivere. Spesso ad una codifica semantica e gerarchica molto precisa si contrappone una difficoltà molto pragmatica di poter utilizzare tale standard nella trasmissione delle informazioni.

Infatti, chi ha provato a utilizzare IFC si è accorto rapidamente che “uscire” da un programma come Revit verso il formato interoperabile non è poi così un processo standard.

Quest’esportazione infatti segue 4 logiche parallele distinte:

• Mapping Table, cioè una tabella di “equivalenza” tra le categorie di Revit e le classi IFC;
• PropertySet, cioè dei gruppi di proprietà che consentono all’Exporter di “far traslocare” i parametri presenti in Revit verso parametri custom IFC;
• User Defined PropertySet, cioè dei gruppi di proprietà che consentono all’Exporter di “far traslocare” i parametri presenti in Revit verso parametri custom IFC;
• Parameter Mapping Table, cioè una tabella di “equivalenza” tra parametri presenti in Revit verso parametri già definiti nello Schema IFC.

Queste sono procedure automatiche, che seguendo delle impostazioni di base “traducono” delle informazioni, ma che trovano difficoltà a tradurre quelle custom, quelle che il progettista può aver aggiunto all’interno di Revit, e spesso anche quelle di default.

Per ovviare a questo problema, si possono usare gli User Defined PropertySet.

Ora, “mappare” questi parametri all'interno di Revit può diventare, effettivamente, un lavoro lungo: come tanti lavori lunghi in ambito BIM è però, se organizzato in un certo modo, riutilizzabile e migliorabile con grande efficienza.

Esistono essenzialmente due modi per fare questa mappatura:

1. il primo, più celebre ma spesso più ostico, sono i Custom Pset;
2. il secondo sono i Pset Schedule.

I Custom Pset si compongono sostanzialmente di un file di testo (quello di default e d’esempio è appunto DefaultUserDefinedParameterSets), che spiega al software quale parametro di Revit va messo in quale parametro IFC, e dove va posizionato questo parametro.

Il file fornito di default con Revit contiene questo testo:

#    PropertySet:   <Pset Name>  I[nstance]/T[ype]   <element list separated by ','>

#      <Property Name 1>   <Data type>  <[opt] Revit parameter name, if different from IFC>

Questo file di testo, la prima volta che lo si apre e soprattutto se non si è abituati a modificare impostazioni “profonde” nei software che usiamo, sembra davvero ostico.

In realtà non è altro che un file tabulato, cioè un file apribile come foglio elettronico (ad esempio con Excel o Fogli), e che a ogni TAB fa corrispondere una colonna. Se non siete abituati a usare file tabulati potete salvarlo in .xls e ogni volta che volete caricarlo in Revit, salvarlo in formato .txt.

Qui un esempio:

#                  
# Lombardini22 PropertySet Definition File                 
# All rights reserved                  
#                  
#                  
PropertySet: PsetSuperProfessional     T      IfcSlab,IfcWall
       Family Name  Text   Family Name
       Type Name    Text   Type Name

Revit Category      Text   Category

Una volta creato, va caricato qui:

Il secondo modo, più “User Friendly”, di creare Pset personalizzati consiste nel creare uno Schedule (Abaco per chi usa Revit Italiano), inserire nel nome dello Schedule le sigle IFC o Pset, flaggare l'apposito flag nel IFC Exporter e…. Il gioco è fatto!

Peccato che…questo metodo per alcune cose manchi l’obiettivo... Ad esempio, per aree di pavimenti creati con due “loop” in un unico oggetto (cioè con due contorni chiusi, separati, in un unico oggetto), rischia di creare dei problemi: questa è infatti da noi in Lombardini22 inserita nel podio delle Worst Practice.

Best Practice di esportazione del database IFC

Oltre a quanto già visto sopra, vi sono altri “errori” che vengono fatti da Revit nella scrittura degli IFC e dei Custom Pset.

Esportando ad esempio il parametro Function come testo, quello che all’interno di Revit ci consente di differenziare ad esempio la funzione Interna o Esterna di un muro, non si avrà alcun valore.

Function     Text   Function

Questo perchè il parametro va esportato come “Count”, così:

      Function     Count  Function

Peccato però che, così facendo, il parametro nel file IFC verrà compilato come numero intero, per questo parametro ad esempio da 0 a 6: ogni valore corrisponde al “posto” nella lista dei valori possibili.

Valori come questi, sono quindi correggibili tramite script, o “trova e sostituisci”, fermo restando che il problema dell’exporter IFC rimane.

Altra problematica che si incontra riguarda i comandi modify profile e attach, nativi di Revit per i muri: è bene tener presente che si potrebbe incorrere in alcuni “errori” nel modo in cui vengono riportate le altezze.

Infatti nell’IFC esportato:

• l’altezza è riportata correttamente in “height”, ma non in “unconnected height” dove è riportata l’altezza memorizzata precedente al “modify profile” o al comando “attach”;
• le altre dimensioni risultano coerenti
• a seconda che prima di eseguire il comando modify profile sia stato impostato un vincolo superiore, compare “top constrain” o meno;
• non vi è indicazione del fatto che il profilo sia stato modificato (in quanto comando nativo di Revit)

[...] continua la lettura nel PDF allegato