En un breve plazo de tiempo han aparecido en nuestro país varias aplicaciones específicamente orientadas a la extracción de mediciones y la elaboración de presupuestos desde modelos BIM en formato IFC. No parece un hecho casual sino causal. Aceptada esta hipótesis, la causa puede encontrarse en la generalización del uso de archivos IFC como contenedores de información útil.
El IFC, entendido como propuesta de estándar, se consolida como tal. No solo eso, cataliza y articula los diversos caminos y paradas de la metodología BIM. Open BIM Quantities, MAMBA o Presto-IFC (citadas en orden cronológico de aparición) son, al margen de otras iniciativas nacionales de ámbito menor, las aplicaciones recién incorporadas a escena que basan su potencial en el propio de los archivos IFC.
No son, ciertamente, las únicas ni las pioneras. Aplicaciones como TCQ2000 ya miraron hacia el formato IFC hace un lustro. Si la versión 5.0 del programa apostaba por procesos de exportación nativos basados en hojas de cálculo como ficheros de intercambio, la versión 5.1, de diciembre de 2016 abría la vía al uso de IFC como archivo de intercambio entre las aplicaciones nativas de modelado y la del presupuesto, incorporando incluso, para dar visibilidad al proceso, un visor de archivos de este formato. Sin embargo, poco se hablaba de los archivos IFC como generadores y referencia de las mediciones y presupuestos. Hasta ahora.
Un poco de historia
La obtención de mediciones de un modelo BIM no es algo nuevo ni mucho menos; de hecho, obtener una medición es algo tan lógico e inmediato que cabría entenderse como el primer proceso o producto a generar de un modelo BIM, por delante, incluso, de la obtención de planos. Al contrario que otros usos, no requiere de preparación o procesamiento previo del modelo. Por definición, un modelo BIM es un magnífico contenedor de información relacionada con la medición: elementos clasificados y definidos por una geometría paramétrica. Esta información puede ser directamente transferida a lo que se conoce como EDT o Estructura de Desglose del Trabajo, es decir, a una potencial estructura de presupuesto donde los tipos (o agrupaciones de elementos con características comunes) den lugar a unidades de obra y, por su parte, cada elemento individual del modelo de lugar a una línea de medición definida por las dimensiones parciales que conforman su geometría 3D. Por esta razón, la obtención de mediciones es casi consustancial a la existencia de herramientas de modelado BIM. Incluso antes de que el término BIM existiera, los modeladores han tenido capacidad para generar informes de cuantificación con herramientas propias. NOTA: Que todos los modeladores puedan generar mediciones no implica que todos lo hagan con la misma facilidad y/o calidad; pero, este es un melón cuya apertura no procede en esta píldora.
Un modelador BIM utiliza taxonomías internas, es decir, sistemas de clasificación jerárquica para sus objetos; estas taxonomías son fácilmente transferibles a estructuras presupuestarias. Si se dispone de una geometría 3D clasificada, suele haber un procedimiento sencillo e inmediato para filtrar y obtener, de forma automática, la medición de un modelo. Si esta clasificación se relaciona con una estructura presupuestaria, el paso de la medición al presupuesto será igualmente inmediato. Este procedimiento suele añadir, además, un ingrediente fundamental: la trazabilidad; poder identificar y localizar los elementos del modelo relacionados con determinadas líneas de medición, y viceversa, suele ser más convincente que la mejor de las literaturas.
El “modelocentrismo” imperante en los primeros años de difusión de la metodología BIM promovía el trabajo en entornos de modelado nativos, en detrimento de la interoperabilidad abierta y el uso de estándares. Al calor del auge de los modeladores, especialmente de los de mayor difusión, surgieron fantásticas herramientas en forma de plugins o soluciones “ad-hoc” para la obtención automática de mediciones y presupuestos. Cost-It o el complemento de CYPE, nacidos ambos en 2015, son nombres ya habituales y presentes en flujos profesionales y planes formativos; estos plugins, instalados en Revit, operan sobre el modelo nativo para extraer las mediciones con destino final Presto y Arquímedes, respectivamente. Ciertamente, la estructura jerárquica de Revit (categorías > familias > tipos > ejemplares) permite una relación biunívoca con la estructura propia de un presupuesto (capítulos > subcapítulos > unidades de obra > líneas de medición); como también lo permite la estructura propia de un IFC.
El IFC hoy
El formato IFC, su lenguaje y estructura interna, quizás no pueda presumir de “amigable”; esto le ha valido duras críticas y ha alimentado las dudas acerca de su capacidad para establecerse como un estándar verdadero (útil, funcional y universal). No obstante lo anterior, el formato ha ganado presencia de forma progresiva en los flujos de trabajo real, tanto en la empresa privada como en la Administración. Si el incremento de uso es consecuencia de su evolución como formato (con la incorporación de diversas disciplinas y lenguajes) o del convencimiento, por parte de la comunidad de usuarios, de la conveniencia de disponer de formatos abiertos e interoperables (a salvo de dependencias comerciales) no resulta tan relevante para el asunto tratado en este artículo como la constancia de su creciente popularidad.
Si hablamos de IFC en el contexto de una metodología colaborativa, más que de uso deberíamos hablar de usos; al fin y al cabo, un modelo IFC es una “foto fija” de un modelo BIM que incluye un subconjunto de propiedades y valores del archivo nativo original (una Model View Definition define un subconjunto de las definiciones del esquema IFC completo); si el esquema IFC satisface a todas las disciplinas durante todo el ciclo de vida, un archivo IFC particular incluirá un subconjunto necesario para cumplir con los requisitos de uno o varios usos de intercambio concretos.
El IFC y las mediciones
Si nos referimos al uso relacionado con la obtención de mediciones y presupuestos, los requerimientos serán muy básicos; sin entrar en pormenores, podríamos simplificarlos en requisitos primarios de clasificación y en la inclusión de las BaseQuantities; es decir, necesitaremos que los objetos estén tipificados e incluyan datos de dimensiones (longitud, superficie, volumen, etc.). Con ello será suficiente para cumplir con las condiciones necesarias de agrupación, vinculación a unidades de obra de una estructura presupuestaria y establecimiento de un criterio de medición basado en las mencionadas BaseQuantities. Así de simple, sencillo e inmediato. Si en el apartado anterior nos referíamos a categoría, familias, tipos y ejemplares, ahora nos referiremos, de forma más libre, a clases o entidades, tipos predefinidos, tipos de objeto…
La obtención de mediciones supone la punta del iceberg del denominado BIM 5D que, a falta de desglose, haría referencia a la gestión económica global del proyecto a lo largo de todo el ciclo de vida de la construcción. Esta gestión económica global comenzaría con la generación de las mediciones de proyecto y, si se dispone de un modelo BIM, absurdo sería no aprovechar las posibilidades que las herramientas de medición automática ofrecen; tanto por inmediatez como por calidad y coherencia con el modelo definitorio del proyecto. La posibilidad de realizar estas operaciones desde modelos IFC, además, añade una clara ventaja: la independencia de herramientas de autoría de terceros y la garantía de interoperabilidad.
Medir desde modelos IFC resulta rápido, preciso, sencillo, coherente y objetivo; además, permite fácilmente actualizar el presupuesto ante cambios en el modelo de referencia y aplicar la configuración a proyectos similares.
Resumen del proceso
Las aplicaciones citadas orientadas a la medición de modelos IFC incluyen un visualizador propio, lo que contribuye a, por un lado, garantizar la independencia frente a otras aplicaciones y, por otro, permitir la consulta de la información contenida y vinculada a los objetos potencialmente medibles. Estos visores permiten verificar que, efectivamente, los objetos están suficientemente definidos y clasificados y su geometría se incluye en las BaseQuantities, condiciones necesarias y suficientes para iniciar el proceso. Por supuesto, estos visores también permitirán comprobar la trazabilidad, entendida como relación entre elementos del modelo (o grupos de elementos) y líneas de medición (o partidas).
Realizadas las verificaciones y consultas oportunas, el proceso general (que obviamente presentará las particularidades propias de cada aplicación) consistirá en el establecimiento de reglas y criterios que filtren los objetos, creen agrupaciones, asocien unidades de obra y definan una fórmula de medición basada en las dimensiones contenidas en las BaseQuantities. Simplificando, estas reglas traducirán cuantitativa y cualitativamente, los componentes del modelo en líneas de medición cuantificadas pertenecientes a unidades de obra.
NOTA: Una interfaz amigable ayudará al usuario a crear las compuertas lógicas y resto de operaciones booleanas y de asociación que permiten la gestión de la información contenida en el archivo IFC.
Por supuesto, la aseveración anterior admite las lógicas alternativas, variaciones y excepciones. El procedimiento “ortodoxo” basado en reglas y criterios puede ser, en función de las alternativas ofrecidas por las diversas aplicaciones, transformado en procesos alternativos; más simples o más complejos. Más simples, por ejemplo, consistentes en arrastrar elementos seleccionados en el visor sobre unidades de obra de la estructura del presupuesto para con ello generar una vinculación completamente manual; más complejos, por ejemplo, mediante la combinación de bases de precios paramétricas y la propia naturaleza paramétrica de los objetos de un modelo BIM para, con las reglas apropiadas, automatizar la generación de unidades de obra hasta el punto de que sean los propios objetos BIM los que generen las partidas diferenciadas necesarias.
En cualquier caso, la ortodoxia exige el uso de reglas y criterios de medición para garantizar la eficiencia y coherencia del proceso y, sobre todo, la posibilidad de repetición. Establecido un conjunto de reglas válido para un proyecto, su guardado permitirá su aplicación posterior al mismo proyecto, a sus variaciones, o, con las necesarias adaptaciones, a proyectos similares.
Este planteamiento, similar siempre en su fondo, podrá diferir formalmente en las distintas aplicaciones. La alternativa a la definición expresa de reglas y criterios mediante agrupación de condiciones y asociaciones recogidas en un listado podrá ser sustituido por una manipulación directa sobre la matriz global de los datos contenidos en el archivo IFC y en cada una de las clases o entidades reconocidas; la elección de determinadas propiedades diferenciadoras creará potenciales unidades de obra también diferenciadas, siempre en función de los distintos valores recogidos por cada objeto individual.
Se agradece la existencia de alternativas que permitan al usuario decidir el procedimiento que más se adapte a sus necesidades o intereses particulares; pudiendo optar por planteamientos gráficos, apoyados en el visor, o analíticos, apoyados en la matriz de propiedades y valores individuales; por el establecimiento de criterios de medición recogidos de forma expresa o implícita.
Recientemente, en la 32ª Reunión del Grupo de Usuarios BIM de Málaga realicé una demostración de cómo medir IFCs con las aplicaciones citadas anteriormente.
Retos de la automatización de mediciones desde modelos IFC
Afortunadamente, los retos que plantea la obtención de mediciones desde archivos IFC dependen de factores externos, tanto al potencial del archivo IFC como de los procesos descritos.
- Porcentaje de obtención a obtener de los modelos. La cuestión es simple; para poder obtener el 100% de la medición desde el modelo BIM, debería estar correctamente modelado el 100% elementos presupuestables. Esto obviamente no es posible, y no lo es por dos razones; la primera que hay partidas o tareas que no se pueden modelar (por ejemplo, una canon de vertedero) y la segunda, que aun siendo posible, no resulta conveniente (sucede, por ejemplo, con las armaduras o el encofrado de los pilares). En todo caso, llegar a un 60-70-80% parece razonable sin grandes esfuerzos; de hecho, bajo dominios como el IFC Road y modelos de carreteras, es posible alcanzar ese porcentaje con un reducido grupo de partidas.
- Hilando con el punto anterior, en un escenario ideal, cada elemento del modelo se corresponderá con una unidad de obra. Raramente sucederá esto; un elemento del modelo podrá dar lugar a varias unidades de obra (pilar: hormigón, encofrado, cuantía de armadura, aislamiento, control de calidad…) y, a la inversa, elementos con distinta clasificación en el modelo podrán converger en una misma unidad de obra (el forjado estructural podrá ser creado desde elementos de cubierta, IfcRoof, o forjados entre pisos, IfcSlab). Tampoco será esto problema para las aplicaciones que podrán recoger criterios y reglas que establezcan relaciones no biunívocas.
- Es evidente que los flujos están optimizados para el dominio de edificación. El esquema IFC continúa agregando nuevos dominios (IFC Road, IFC Rail, IFC Bridge…) que, pendientes de maduración, no han sido implementados en las distintas aplicaciones de modelado. Como consecuencia de esta falta de alineación, modelos IFC de infraestructura presentan una taxonomía mucho menos estandarizada que las generadas desde modelos de edificación. Esta circunstancia tampoco debería suponer un gran problema para su medición (al fin y al cabo las herramientas presentadas permiten “jugar” con parámetros y propiedades tanto estándar como nativas o personalizadas, suficientes para permitir el necesario filtrado y agrupación de objetos). No obstante, la alineación de las aplicaciones de modelado de infraestructuras con los nuevos dominios recogidos por el esquema IFC permitirá, en el futuro próximo, una mayor ergonomía de uso.
- Bidireccionalidad. En una píldora firmada en 2019 lanzaba una pregunta razonada: ¿Es necesario editar IFC's? Hoy, no solo me reafirmo en esa necesidad sino que lo hago con mayor convencimiento. Es evidente que, en general, un modelo IFC debe respetar la autoría de su creador; sin embargo, necesitamos que ciertas aplicaciones de gestión económica se relacionen de forma bidireccional con los IFC’s; sólo de esta forma se podrá utilizar un modelo como referencia más allá de la fase de obtención de mediciones, garantizando la interoperabilidad defendida desde el inicio de este artículo. Ya es posible a día de hoy (al fin y al cabo, un IFC es un archivo de texto plano) pues existen en el mercado aplicaciones que permiten una edición más o menos puntual desde la interfaz de usuario. Cuando esto no es posible o resulta demasiado laborioso, se puede hacer uso de archivos de datos (por ejemplo, vía bases de datos semiestructuradas) o, directamente, atacar el IFC vía scripts de programación en entorno Python o IFC.js. Sin duda, las aplicaciones evolucionarán para permitir un grado de interacción sobre archivos IFC similar al que hoy día se ofrece sobre modelos nativos vía API. De esta forma se democratizará la posibilidad de añadir a modelos IFC información necesaria para fases de desarrollo posterior (planificación, certificación, etc.).
No podemos cerrar esta píldora sin citar a un gran aliado en el proceso de interoperabilidad 5D: el formato FIEBDC (más conocido como “BC3”). No se trata de un formato desarrollado por la BuildingSMART pero, en nuestro país contamos con la gran suerte de disponer de este estándar reconocido (que define y supervisa la Asociación FIE-BDC) y que permite al usuario final intercambiar de forma cómoda y libre información entre diferentes agentes que usan distintas aplicaciones de presupuestos y bases de datos de la construcción, lo que garantiza una interoperabilidad de estructuras presupuestarias similar a la ofrecida por IFC para el intercambio de modelos BIM.
La versión más reciente del formato FIEBDC contempla el “Enriquecimiento de modelos BIM con datos del presupuesto en formato BC3”. Aunque sería deseable un completo alineamiento de este formato con el esquema IFC (uno que agotase los atributos y conjuntos de propiedades estándar), disponer de un lenguaje común para el intercambio de bases de datos y presupuestos entre las distintas aplicaciones mencionadas en este artículo cierra, en cierto modo, el círculo de la interoperabilidad.
Autor
Marco Pizarro , es Arquitecto, con experiencia en muchos campos (alumno y profesor universitario, técnico municipal, de visado, de centros de asesoramiento colegiales, calculista, diseñador...) y, desde hace unos años, usuario, consultor, formador, beta tester y apasionado de la metodología BIM.
Además, Marco es uno de los coordinadores del proyecto Comunicación con BCF de buildingSMART Spain, y es Copresentador, junto a Javier Sánchez-Matamoros y José A. Canovas, de BIM Podcast
Escribir comentario
Marco A. Pizarro (martes, 08 marzo 2022 11:54)
Pena que todo el debate y comentarios se haya desplazado a Twitter, donde se perderán "como lagrimas en la lluvia"...
https://twitter.com/buildingSMARTsp/status/1500783206668247040
Marco A. Pizarro (martes, 08 marzo 2022 11:55)
*lágrimas
Pilar Jiménez (miércoles, 09 marzo 2022 08:08)
Estupendo artículo, Marco.
Yo creo que sería interesante hablar y difundir sobre:
- Herramientas de generación de presupuesto a partir de IFC: TCQ, OpenBIM Qtt, Presto IFC, Mideplan + Gest, Primus IFC... etc (y si me apuras, BIMvision con el plugin Advanced Report)
- Herramientas de visualización gratuitas de presupuesto trazable contra IFC: Visual Cost y Direct BIM 5D (no conozco más)
Las primeras son las utilizadas por equipos que generan presupuestos. Las segundas, por personal que espera revisarlo como haría antes con pdf's de salida (resumen de presupuesto, presupuesto, listado de precios... etc y los propios planos). Lo interesante de estas segundas es que permiten ver la relación entre las dos bases de datos:
- el .bc3 que es el archivo que contiene el presupuesto
- el .ifc que es el archivo que contiene la geometría medida
Si las primeras herramientas lo hacen bien (que implica generar la relación entre elemento y partida en la línea de medición correspondiente añadiendo #IfcGuid), las segundas podrán mostrar la relación. Ejemplo:
Losa de cimentación#54535eewasdfsdedasd
Lo cuenta muy bien Ferrán Bermejo en este vídeo de mayo 2020: https://www.youtube.com/watch?v=dv0olAVDZE8&t=1602s
A día de hoy se está buscando agregar manualmente al IFC tediosos Pset de presupuesto tratando de incorporar una base de datos que ya está contenida en el BC3. A mi juicio es una complicación INNECESARIA: pensemos cuanto tiempo resta desde que terminamos el presupuesto hasta ue entregamos. Bien, pues con esos Pset parece que nadie está observando que ese tiempo hay que ampliarlo varias semanas más porque hay que extraer datos del presupuesto y facilitárselo al modelador para que los incorpore. No es sencillo y tampoco el proceso es fiable. La única herramienta capaz de agregar dichos datos al IFC (que no a los archivos de modelo nativos) es TCQ pero el Pset y las properties no se llaman como pide la AAPP de turno que se nombren.
Reconozco llevar año y medio ansiosa esperando este debate pues estamos asistiendo a la publicación de múltiples manuales BIM de AAPP en donde solicitan esto cuando es mucho más eficiente para las ingenierías y constructoras aprovechar estas soluciones que mencionas en tu artículo para genera el presupuesto y naturalmente, más eficiente para dichas AAPP utilizar esos visores para la comprobación en lugar de dichos Pset's.
Y ese es el motivo por el que creo imprescindible que quienes estamos dedicados a estos aspectos en BIM hagamos una labor de difusión como la que tú haces. Muchas gracias.
Pilar Jiménez
Ferran Bermejo (jueves, 10 marzo 2022 11:04)
Gracias Marco por el esfuerzo de síntesis. Aun así, creo que debo hacer algunas aportaciones para precisar mejor el contenido del mismo.
Desde luego TCQ figura como uno de los pioneros en la apuesta firme por IFC en el marco del trabajo colaborativo para la realización de presupuestos. Aunque como bien dices la primera versión para BIM solo utilizaba tablas (TCQ 5.0, enero 2016), a partir de la versión 5.1 de enero de 2017 ya incorporó los IFC convirtiéndose en una herramienta auténticamente multiplataforma, es decir realmente colaborativa.
TCQ, está preparado para que la medición y presupuesto de un proyecto puede obtenerse mediante la vinculación a diversos IFC, procedentes cada uno de ellos de distintas disciplinas, y quizás también producidos con distintas plataformas de modelado. Además, admite mezclar datos procedentes de tablas o mediciones indirectas para todo aquello que no está modelado.
Esto rebate la idea de quienes no ven necesario hacer presupuestos a través de IFC porque están subyugados a una única plataforma, la de siempre. La realidad les contradice ya que como estamos viendo, todos los programas especializados en este tema están cambiando su estrategia y convergiendo al uso de IFC.
Comentas en tu artículo con referencia a TCQ que “poco se hablaba de los archivos IFC como generadores y referencia de las mediciones y presupuestos”. Esta afirmación está en contra de lo que realmente estaba proponiendo TCQ desde el principio, la vinculación de la medición al IFC y los tipos BIM definidos, exprimiendo al máximo la información que contiene.
Por cierto, y aunque lo he explicado repetidamente, los programas de modelado nos permiten extraer datos que tienen carácter de “recuento” que no es lo mismo que una “medición”. A veces coinciden, y otras muchas no. Por ello es tarea casi imposible sacar automáticamente una medición completa de un programa de modelado.
TCQ, con su sistema asociativo, resolvió ya desde el principio la vinculación de diversas unidades de obra a un elemento del modelo. Añadiendo funcionalidades de fórmulas condicionales con las que, por ejemplo, las ingenierías de instalaciones ven muy favorecido su trabajo.
Por otra parte, los datos contenidos en el IFC para realizar la medición, no sólo provienen de un Pset “Base quantities”, pueden utilizarse datos de cualquier Pset. Eso también se resolvió des de muy al principio en TCQ, permitiendo el uso de cualquier atributo de cualquier Pset, máxima flexibilidad.
Respecto a los retos planteados en la parte final del artículo, comento que el punto 2 está resuelto en TCQ desde sus inicios. Es un tema ya superado.
No creo en la edición del IFC en este terreno (si en otros, especialmente si se convirtiera en nativo…) ya que perdemos un aspecto básico en el rigor presupuestario de proyectos, como es el de tener claro a que momento evolutivo del proyecto responde una medición o presupuesto. La edición del IFC introduce una “liquidez” que en este caso los especialistas suelen rechazar.
En cambio, si que es muy interesante que los IFC de entrada (IFC input) para realizar un presupuesto, puedan enriquecerse al final del proceso obteniendo un nuevo IFC (IFC otput) con las mediciones, costes, unidades de obra, etc. Esta funcionalidad también se halla implementada en TCQ desde las primeras versiones, aunque por lo visto no es muy conocida por los no usuarios.
La entrada en escena del estándar eCOB®, permite tipificar todos esos atributos que enriquecen el IFC. De hecho, aunque no se utilice el estándar en toda su amplitud, es posible una utilización parcial del denominado eCOB_Pset_5D, con el cual se organiza toda esta información de manera sencilla, clara e interoperable. No quisiera pasar por alto, la oportunidad que tienen los modeladores de utilizar este mismo Pset para incorporar las unidades de obra de los elementos del modelo, vinculadas a cualquier base de datos existente y facilitar así la automatización de procesos. Pero este es ya otro tema.
@Pliar Jiménez, en un comentario anterior a esta píldora, define muy acertadamente lo que hace TCQ, basándose en los dos formatos estrella. La suma del bc3 y el ifc son la base para disponer de instrumentos gratuitos de auditoria/revisión como VisualCost para trabajar en un ambiente BIM, sin necesidad alguna de disponer de ninguna licencia ni de programa de presupuestos, ni de modelado. En su comentario también comenta que “La única herramienta capaz de agregar dichos datos al IFC (que no a los archivos de modelo nativos) es TCQ pero el Pset y las properties no se llaman como pide la AAPP de turno que se nombren.” Justamente lo comentado en el párrafo anterior sobre el uso, aunque sea parcial, de eCOB® apunta a la solución de este problema.
Espero haber podido enriquecer tu artículo, y te sugiero quizás una versión ampliada del mismo. A tu disposición para la ayuda que precises.
Juanjo Sánchez-Bayo (lunes, 28 marzo 2022)
Quienes nos dedicamos - desde la parte constructora - al análisis y revisión de proyectos redactados con software de autoría BIM, estamos encantados de que se apueste por la interacción IFC – mediciones y presupuestos. Además, desde mi punto de vista, es la única opción de futuro, toda vez que no podemos analizar proyectos complejos desde sus variados formatos nativos. Es cierto que no contiene la misma información un IFC exportado desde un software u otro, incluso con diferentes configuraciones de exportación dentro del mismo software, pero la apuesta por un formato compatible estandarizado como IFC a la larga será beneficiosa para todos, toda vez que es fácil extraer la información incluida en este archivo.
Que yo sepa, hasta ahora, TCQ (a pesar de necesitar corregir ciertos errores) es el único programa que apostó por vincular el formato IFC con la medición-presupuesto, y no se inclinó a interactuar únicamente con Revit vía plugin.
Por cierto Ferrán, muchos usuarios de TCQ si conocemos esa opción tan útil (si funcionara) de enriquecer el IFC con datos del presupuesto. Lo que ocurre es que en proyectos de tamaño mediano a grande nunca funciona (el propio departamento técnico de ITEC lo reconoce y parece ser que llevan tiempo intentando solucionarlo). En cualquier caso, desde mi punto de vista de usuario, este es el camino correcto.
Agustí Jardí (martes, 29 marzo 2022 21:37)
Siguiendo el hilo de comentarios, que se empiece a hablar de IFC como base de datos y fuente de información para generar presupuestos, y que en definitiva la gran mayoría de herramientas de presupuestos del mercado hayan decidido dar ese paso es muy positivo. Tenemos que estar contentos. Esto es una muestra real y pragmática de los beneficios del OpenBIM y del IFC, como vector de transmisión de información. El caso de uso corresponde a disponer de los datos geométricos de los elementos del modelo para que luego, con el "expertise" de los agentes se puedan convertir en líneas de medición de nuestro presupuesto y para cada una de las partidas.
Quizá en los proyectos de infraestructuras, en donde por unas razones u otras conviven más herramientas de modelado, el IFC pese a muchos y a tener muchas resistencias por parte de lo usuario "es un mal necesario". Es la única forma de canalizar con rigor una estructura de información que se ha podido originar en diferentes herramientas de Autoría - Modelado (varias de trazado, estructuras, algunas para el drenaje, ...) de forma que para un agente que realiza el presupuesto, el origen del IFC es lo de menos. Es más, para un proyecto de infraestructuras, no queda otra: usar el IFC es la forma de canalizar por igual toda esa información sin atender a especialidades, herramientas y demás: todo debe de llegar igual.
Por otro lado, y un aspecto a destacar es que muchos de los técnicos y agentes del sector que tienen la experiencia de hacer presupuestos, no tienen los conocimientos necesarios (y a veces ni tiempo para adquirirlo) de las herramientas de modelado BIM y consecuentemente los addins de conexión con las herramientas de presupuestos. En muchos casos, se sometía a que el experto de presupuestos además tenía que aprender a manejar la herramienta de autoría. Por tanto, utilizar el IFC como base para elaborar presupuestos puede permitir una mayor penetración del uso del BIM por parte de los agentes del sector, y eliminar ciertas barreras. De esta forma, facilitamos la entrada a la gestión digital de nuestros proyectos, a un mayor número de técnicos. Como sector no nos podemos permitir dejar a un lado a un gran número de agentes que todavía pueden y tienen que aportar mucho.
Ferran Bermejo (viernes, 01 abril 2022 11:54)
En respuesta a @Juanjo Sánchez-Bayo, en su entrada anterior en este hilo, en la que comenta: "Lo que ocurre es que en proyectos de tamaño mediano a grande nunca funciona (el propio departamento técnico de ITEC lo reconoce y parece ser que llevan tiempo intentando solucionarlo). En cualquier caso, desde mi punto de vista de usuario, este es el camino correcto."
Este tema está resuelto en la revisión de TCQ 5.8 publicada la primera semana de abril de 2022. El IFC enriquecido con la información del 5D no presenta ninguna incidencia vinculada a versión de IFC o tamaño de proyecto.. Aún así, como siempre, desde el ITeC estamos abiertos a recoger cualquier comentario de mejora que los usuarios nos puedan plantear. A parte de la información 5D, los elementos BIM con partidas de obra vinculadas aparecen coloreados, mientras que los que no las tienen, aparecen con transparencia. En una revisión próxima, esto último será una opción que el usuario podrá seleccionar en el momento de exportar el IFC desde TCQ. Con ello se consiguen archivos mucho más ligeros.