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:
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:
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:
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.
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:
[...] continua la lettura nel PDF allegato
News Vedi tutte