183 openBIMathon round 2

183 openBIMathon round 2

Porque una cosa es hablar de estándares abiertos y otra muy distinta es usarlos a contrarreloj, con un modelo estropeado a propósito y una hoja de requisitos escrita en jeroglífico BIM. El Open BIMatón no es un evento para posturear en LinkedIn: es un campo de pruebas donde las herramientas, los procesos y tus nervios se ponen al límite. Y en esta edición, el enemigo tenía nombre y apellido: Information Delivery Specification.

En este episodio te contamos cómo fue enfrentarse a la validación de un modelo real con IDS, cómo sobrevivimos a los falsos positivos, a las reglas que no se dejaban domar y a las incidencias que nadie sabía cómo comunicar (pero que había que entregar igual en BCF). Si crees que lo tuyo es el openBIM, prepárate: esto va con XML, con errores que no avisan… y con fartons.

¿Modelar está bien, pero validar es mejor?

Modelar sin validar es como cocinar sin probar la comida. Puede parecer que está todo bien, pero el día del banquete algo va a fallar. Y si lo que falla es un parámetro de resistencia al fuego, igual no es solo la reputación lo que se quema.

El ejercicio del BIMatón puso sobre la mesa una realidad incómoda: muchos modelos contienen información, pero nadie sabe si esa información es correcta. IDS se presenta como la solución para eso. Te permite convertir los requisitos en reglas claras y comprobables, aplicables a modelos IFC de forma automatizada.

Y eso cambia las reglas del juego. Porque ya no basta con que el modelo “parezca” bien. Ahora puedes demostrarlo. Puedes auditarlo. Puedes corregirlo. Puedes replicar ese proceso en todos tus proyectos sin reinventar la rueda.

Pero hay un problema: traducir de lenguaje natural a IDS no es tan natural. A veces, entender lo que te están pidiendo es más difícil que aplicarlo.

¿Por qué no todo el mundo está usando esto?

Si IDS funciona tan bien, ¿por qué no se usa más? Porque hace falta algo que escasea: criterio técnico.

No basta con conocer Revit, Archicad o el visor de moda. Necesitas entender el esquema IFC. Necesitas saber cómo se estructuran los datos, qué propiedades son requeridas, cómo identificarlas. Y después traducir eso a una lógica XML que un software pueda entender y validar.

Por eso muchos se limitan a entregar modelos con la esperanza de que nadie los revise. Porque si lo hicieran, descubrirían que lo que hay dentro del archivo IFC es una piñata de promesas rotas.

Y luego está el tema de las herramientas. Algunas permiten aplicar IDS, otras no. Algunas validan bien, otras se cuelgan. Algunas colorean elementos, otras devuelven informes. Pero pocas, muy pocas, permiten editar el modelo IFC para corregirlo sin liarla.

Blender + Bonsai: cuando lo open no es lo pobre

En medio del caos, un rayo de esperanza: Blender + Bonsai. Un combo que no solo validó los modelos, sino que los editó, los documentó y les devolvió la dignidad.

Mientras otros grupos se debatían entre qué software usar, los BIMrras lo tenían claro. Bonsai no es solo bonito por fuera. Es potente por dentro. Y permite cambiar propiedades de forma masiva, revisar estructuras de datos y ajustar el modelo IFC sin pasar por herramientas de autoría.

¿Es perfecto? No. Pero para el BIMatón fue el MVP. La herramienta que les permitió hacer en una jornada lo que muchos no consiguen en una semana con todo el ecosistema Autodesk.

Y lo mejor: sin depender de licencias propietarias ni flujos cerrados. Eso sí que es openBIM con mayúsculas.

¿La validación automática es infalible? Spoiler: no

Durante el ejercicio, hubo reglas que funcionaron a la primera. Otras que no había por dónde cogerlas. Algunas devolvían errores inesperados. Y otras, directamente, exigían malabarismos lógicos para expresar algo que en papel parecía sencillo.

Porque sí, IDS es potente. Pero también tiene sus costuras. Falta expresividad para ciertos filtros. No puedes excluir clases con facilidad. No hay una forma directa de seleccionar todos los elementos instanciados desde una clase abstracta. Y tienes que recurrir al atributo Tag como si fuese un comodín.

Esto no es necesariamente malo. Significa que el estándar está en evolución. Que aún se está estirando. Que el BIMatón sirve precisamente para detectar esas limitaciones. Pero también deja claro que, para trabajar con IDS, hay que tener cintura técnica. Y mucha paciencia.

¿Y si los requisitos están mal redactados?

Otro de los grandes retos no vino del modelo, ni del software, ni del estándar. Vino del documento de requisitos de información. Porque una cosa es que te digan “comprueba los parámetros de los elementos arquitectónicos” y otra es que te especifiquen “busca el atributo FireRating en todos los IFCWallStandardCase que estén en la planta baja y tengan material no combustible”.

La primera es ambigua. La segunda es trabajable.

En el ejercicio, los participantes se encontraron con requisitos “precocinados”. Más claros de lo habitual. Más dirigidos. Menos parecidos a la vida real. Lo cual ayudó a avanzar… pero restó un poco de realismo al reto.

Porque la verdad es que en el día a día nadie te lo pone tan fácil. Interpretar, deducir, negociar y traducir son habilidades clave. Y eso no lo hace ni el IDS ni ChatGPT. Lo haces tú.

¿Es IDS cosa de frikis o de equipos reales?

La experiencia dejó algo claro: IDS no es para frikis. Es para equipos que quieran trabajar bien. No hace falta ser un gurú del IFC, pero sí tener un mínimo de comprensión del estándar. No hace falta ser un desarrollador, pero sí saber qué hace cada botón.

Un equipo bien equilibrado —como el de BIMrras— combina perfiles técnicos con visión estratégica. Gente que sabe leer entre líneas, usar herramientas con sentido y no se asusta ante un XML.

Y sobre todo, gente que entiende que validar no es castigar. Es asegurar calidad. Garantizar que el modelo sirve para algo más que para llenar el disco duro.

¿Y si todo esto nos lleva a un BIM mejor?

Tal vez la conclusión más importante sea esta: IDS puede ser el punto de inflexión que necesitábamos para dejar de improvisar. Para dejar de confiar en que el modelo «seguro que está bien». Para trabajar con datos que se pueden revisar, compartir y escalar.

Es un lenguaje común. Una forma de hablar con máquinas sobre calidad. Una puerta a procesos más coherentes, más repetibles, más confiables.

Eso sí, como todo lenguaje, hay que aprender a usarlo. Pero cuando lo dominas… no hay vuelta atrás.

Recursos citados en este episodio

• Blender
• Bonsai (antes BlenderBIM)
• IfcOpenShell
• IDS (Information Delivery Specification)
• BCF (BIM Collaboration Format)
• buildingSMART International