IFC vs RVT...e non solo!
La quotidianità di un professionista AEC coinvolto nella creazione di modelli formativi è spesso costellata di problemi. La maggior parte di questi è sostanzialmente causata da software non sempre performanti, così come ho raccontato nel mio ultimo post BIM Pratica vs Teoria.
Tuttavia, spesso si è portati ad additare come problematico ciò che, almeno formalmente, un problema non è: parlo del formato IFC.
IFC ha sicuramente i suoi problemi, come tutti, ma sarebbe spesso il caso di chiedersi: lo sto usando correttamente?
Il formato IFC nasce con uno scopo chiaro: scrivere e tradurre in un linguaggio universale e liberamente leggibile, gli oggetti informativi/BIM generati da software che, altrimenti, salvano i propri oggetti in formati proprietari. Si può immaginare il formato IFC come una lingua franca nata dalla estrapolazione, dalla sintesi, di proprietà comuni ai vari linguaggi del mondo AEC. Di contro, essendo per l’appunto una sintesi, l’utilizzo di questa lingua franca comporterà sempre un compromesso, così come avviene nella linguistica, ove è altamente improbabile che ogni termine di una specifica lingua X sia traducibile in uno specifico termine del linguaggio franco Y, vi sarà sempre un lost in translation.
Facciamo un esempio:
Un professionista AEC sta lavorando con un software di BIM Authoring chiamato A. Il software è progettato stilisticamente con il paradigma della programmazione orientata agli oggetti AEC; pertanto, dispone tra le altre, di una classe muri A dotata di proprietà predefinite denominate H, L e X. Inoltre, il professionista decide di aggiungere alla classe muri A una proprietà personalizzata K. Ne consegue con ogni istanza @A della classe muri A, che il professionista AEC creerà, avrà in sé queste proprietà.
Ad un determinato istante T, il professionista AEC è chiamato condividere il modello informativo con un altro attore del processo edilizio. Quest’ultimo, tuttavia, utilizza per il proprio lavoro un software di BIM Authoring chiamato B, che non supporta la lettura dei file del software A. Il professionista AEC è pertanto chiamato all’utilizzo del formato IFC.
IFC, in quanto compromesso tra software diversi, riconosce come caratteristiche predefinite della classe muri IFC le sole proprietà H e L. Ne consegue che le istanze di muro @A tradotte in istanze di muro @IFC, porteranno con sé le sole proprietà H e L perdendo le restanti.
Una volta importato il file IFC nel Software di BIM Authoring B, la classe muri B, riconosce e assegna alle istanze di muro @B le sole proprietà H e L, tralasciando eventuali altri proprietà come la proprietà Y tipica della classe muri del software B, perché non rintracciabile in IFC.
Esportazione IFC
Dall’esempio si evince che potenzialmente si è liberi di inserire di tutto in un modello informativo quando si lavora nel software di BIM Authoring A (proprietà personalizzate K), ma non si può dire che IFC sia un problema perché le proprietà personalizzate non si trasmettono, il formato non nasce per quello. È come usare un programma di traduzione forzatamente limitato a 15 vocaboli, per poi lamentarsi dell’incapacità dello stesso di tradurre efficacemente un testo composto da 742 vocaboli. IFC non perde pezzi, ma non può portare con sé quello che non può sapere.
Eventualmente, per risolvere questo inevitabile collo di bottiglia, si può ricorre alla creazione di proprerty set (gruppi di proprietà) personalizzati (che contengano ad esempio i parametri X e K della classe muri A) da affiancare ai property set predefiniti (ad es. parametri H e L). Tuttavia, è un’operazione che va sempre ponderata con attenzione, perché così come accade con i modelli generici (vedi articolo n.4) la macchina non sa cosa sono questi dati. Li porta con sé, li vede, però è un testo scollegato da tutto. Bisogna essere pienamente coscienti che nessun altro software di lì in poi saprà cosa era in origine quel dato e dove era incasellato.
IFC è chiaramente un qualcosa che andrebbe migliorato, basti pensare, ad esempio, che è scritto in linguaggio di programmazione veramente vecchio (linguaggio STEP), che tuttavia è ancor’oggi l’unico modo di trasportare geometrie senza alcun problema a nostra disposizione. Il prossimo linguaggio di scrittura dovrebbe essere di tipo web/xml, dato che tutto il mondo va in quella direzione, però siamo ancora lontani da quel momento. Andrebbe anche espanso con maggior celerità, ad esempio è tutto ora in fase di approvazione una versione di IFC (4.3 ADD2) che aggiunge, per la prima volta, tutta un serie di classi di oggetti di natura infrastrutturale (strade ponti, porti, ferrovie, ecc.) e ci sono voluti oltre 27 anni (prima pubblicazione di IFC nel 1996) per considerare queste aggiunte.
In conclusione IFC non è perfetto, ma spesso, anziché chiedersi perché IFC non funziona, la vera domanda dovrebbe essere: ho capito che vuol dire esportare in IFC?