IfcOpenShell: abre el IFC al código y a tus propias reglas
Te llega un IFC, lo abres y parece estar bien. Hay muros, puertas, espacios y una geometría razonable. El problema empieza cuando intentas responder una pregunta concreta: qué puertas no tienen clasificación, qué espacios han perdido su código o qué elementos han cambiado desde la entrega anterior. Ahí la inspección visual deja de ser suficiente y el modelo empieza a parecerse bastante a una base de datos con formas.
IfcOpenShell sirve para trabajar con esa información mediante código. Puede leer, escribir y procesar IFC, y además incorpora un motor geométrico y herramientas como IfcConvert. Dicho así suena a navaja suiza, pero no necesitas desplegar todas las hojas. Para revisar propiedades quizá baste Python; para convertir archivos por lotes, la línea de comandos; para autoría visual, Bonsai puede tener más sentido.
La decisión importante no es aprender IfcOpenShell “entero”. Es saber qué pregunta quieres hacerle al modelo, qué resultado considerarás correcto y cuánto mantenimiento puedes asumir. Si eso no está claro, el script solo conseguirá que la confusión termine antes.
Tabla de contenidos
Qué aporta IfcOpenShell cuando el visor ya no basta
Un visor te permite recorrer el edificio, aislar elementos y consultar propiedades. Es perfecto para muchas revisiones. IfcOpenShell empieza a compensar cuando debes aplicar el mismo criterio a varios archivos, combinar datos con un catálogo externo o producir un resultado que pueda repetirse y auditarse.
IFC no es una tabla plana. Una propiedad puede pertenecer a la instancia, venir del tipo o estar dentro de un conjunto de propiedades. El elemento también participa en relaciones espaciales y puede tener una representación geométrica bastante más compleja de lo que su aspecto sugiere. La biblioteca evita que tengas que interpretar el fichero STEP a mano y te ofrece una API para navegar por esa estructura.
Las fuentes oficiales actuales describen soporte para esquemas como IFC2X3, IFC4 e IFC4X3 y varios formatos del ecosistema. Aun así, comprueba siempre la versión instalada y los archivos que producen tus exportadores. “Compatible con IFC4” no significa que dos aplicaciones organicen cada dato de la misma manera. Quien haya perseguido alguna vez un FireRating sabe de qué hablo.
Primero decide si vas a consultar, validar o transformar
Consultar es recuperar información: cuántos espacios no tienen código, qué tipos de muro aparecen o qué valores utiliza un parámetro. Validar añade una regla: el código debe existir, seguir un patrón y aplicarse a determinados espacios. Transformar implica modificar el modelo o generar otro artefacto. Son niveles de riesgo distintos y conviene no mezclarlos desde el principio.
Si solo necesitas un inventario, no cargues geometría ni escribas un nuevo IFC. Si buscas una caja envolvente o preparas un visor, entonces el motor geométrico sí entra en escena. Y si quieres corregir datos, pregúntate antes si realmente necesitas devolver un IFC modificado. Muchas revisiones se resuelven mejor con un informe o incidencias BCF que con una copia “arreglada” cuyo origen nadie recuerda.
Esta clasificación también ayuda a escoger herramienta. IfcConvert resulta práctico para conversiones bien definidas y repetibles. Python encaja en consultas, reglas y cruces con otros datos. C++ queda para desarrollo cercano al núcleo o necesidades de rendimiento muy concretas. No hay premio por elegir la opción más complicada.
Un primer script que haga una sola cosa
Empezaría abriendo un archivo y contando una clase de elementos. No es un ejemplo espectacular, y precisamente por eso es útil: confirma que el entorno funciona, muestra el esquema declarado y te permite observar cómo identifica el modelo cada entidad.
import ifcopenshell
model = ifcopenshell.open("modelo.ifc")
doors = model.by_type("IfcDoor")
print("Esquema:", model.schema)
print("Puertas:", len(doors))
for door in doors[:5]:
print(door.GlobalId, door.Name)Este resultado no demuestra que el modelo tenga todas las puertas ni que estén bien informadas. Solo confirma cuántas entidades IfcDoor has encontrado. Parece una puntualización obvia, pero muchas automatizaciones empiezan a tomar decisiones serias a partir de una consulta que nunca fue diseñada para responderlas.
Añade después una única regla y registra el contexto: archivo, versión de la herramienta, hora, elemento y valor leído. Si una propiedad no aparece, distingue si falta, está vacía o se guarda con otro nombre. “No encontrado” puede esconder tres problemas diferentes, y cada uno necesita una corrección distinta.
De «las puertas deben estar bien informadas» a una regla
Vamos a poner un ejemplo. El requisito dice que las puertas de acceso deben indicar su resistencia al fuego. Todavía no puedes programarlo. ¿Cómo reconoces una puerta de acceso? ¿Qué propiedad contiene el dato? ¿Se permite “N/A”? ¿Qué pasa con las puertas existentes o temporales? Antes del código necesitas alcance, fuente, condición, excepciones y severidad.
Separaría la selección de la evaluación. Primero reúnes las puertas afectadas y guardas por qué ha entrado cada una. Después compruebas el valor. La salida debería incluir el GlobalId, la regla, lo que se encontró y una explicación útil. “Puerta incorrecta” es el equivalente digital a dejar un pósit que dice “revisar cosas”.
Prepara además un modelo pequeño con un caso válido, uno sin propiedad, otro con valor vacío y uno que quede fuera. Si todos producen el resultado esperado, prueba con exportaciones reales. Los falsos positivos suelen aparecer donde viven las convenciones de cada autor, no en el archivo de demostración.
IDS, BCF y bSDD no son tres nombres para lo mismo
Cuando los requisitos se pueden expresar mediante Information Delivery Specification, IDS ayuda a formalizarlos de una manera intercambiable. BCF sirve para comunicar incidencias vinculadas al modelo. bSDD aporta referencias semánticas. IfcOpenShell incluye herramientas relacionadas con estos estándares, pero juntarlos no crea por arte de magia un proceso de calidad.
Puedes usar IDS para describir qué información esperas, ejecutar una comprobación y generar incidencias BCF para los fallos. Después alguien debe corregir el modelo, responder la incidencia y volver a validar. Si ese circuito no existe, tendrás una colección muy bien estructurada de problemas pendientes.
No fuerces cada requisito dentro de una regla automática. Hay comprobaciones geométricas, criterios subjetivos y excepciones de proyecto que necesitan revisión humana. Automatizar sirve para retirar trabajo mecánico y señalar casos; no para fingir que toda decisión BIM cabe en una expresión.
La geometría cambia las reglas del juego
Leer una propiedad y generar geometría tienen costes muy distintos. Para construir una forma visible hay que interpretar representaciones, ubicaciones, unidades y transformaciones. En un modelo grande eso consume tiempo y memoria. Si la pregunta está en los datos, no proceses sólidos por costumbre.
Cuando sí necesites geometría, trabaja con el conjunto mínimo y conserva unidades y sistema de coordenadas en la salida. Muchos “fallos de geometría” son transformaciones aplicadas dos veces o modelos situados en marcos diferentes. Antes de culpar al IFC, comprueba qué coordenadas has recibido y qué espera el sistema de destino.
La detección de colisiones también requiere criterio. Dos sólidos que se cruzan no constituyen automáticamente una incidencia: puede existir un hueco previsto, una tolerancia acordada o geometría auxiliar. El motor encuentra intersecciones; el proceso BIM decide cuáles importan, cómo se agrupan y quién debe resolverlas.
Modificar un IFC sin perder la pista
IfcOpenShell permite escribir y modificar modelos, pero yo no empezaría por ahí. Para un control de calidad suele ser más seguro conservar el original y producir un informe. Si la transformación forma parte del entregable, trabaja sobre una copia, registra cada cambio y vuelve a abrir el resultado antes de darlo por bueno.
No sobrescribas el archivo recibido. Guarda versión de la biblioteca, esquema, configuración y resumen de operaciones. Comprueba que otra aplicación pueda consumir el resultado y repite las validaciones básicas. Que el método de escritura termine sin excepción solo demuestra que el método terminó sin excepción; no que el resto del equipo vaya a recibir el modelo que esperaba.
Versiona también las reglas. Si viven en CSV, JSON o IDS, esos ficheros forman parte de la herramienta. Un informe debe permitir responder qué regla se ejecutó sobre qué modelo. De lo contrario, dos resultados distintos se convertirán en una discusión cuando quizá solo proceden de configuraciones diferentes.
Reglas en CSV: útiles hasta que inventas un lenguaje
Sacar condiciones fuera del código permite que un BIM Manager revise nombres, valores y severidades sin tocar Python. Una tabla con entidad, propiedad, operador, valor esperado y mensaje puede funcionar muy bien si el repertorio de reglas es pequeño y está documentado.
El problema aparece cuando el CSV acumula excepciones, expresiones libres y referencias entre filas. Has creado un lenguaje de programación, pero sin editor, sin depurador y probablemente con una columna llamada “observaciones_final_v7”. En ese punto conviene simplificar el contrato o mover la lógica compleja al código.
Valida siempre la propia configuración. Una propiedad mal escrita no puede producir silenciosamente cero incidencias. El programa debe avisar de que no encontró el campo o no pudo interpretar el operador. Una regla que pasa y una regla que no se ejecuta no son el mismo resultado.
Cómo llevarlo a un proyecto sin construir una plataforma
Elige una comprobación pequeña y verificable, como espacios sin código. Reúne varios IFC reales, documenta las variantes y crea la regla con una salida trazable. Compara después el resultado con una revisión manual y clasifica falsos positivos, falsos negativos y casos no evaluables.
Solo cuando la regla sea estable la incorporaría a un proceso recurrente: recibir archivo, comprobar esquema, ejecutar controles, generar informe y conservar el registro. Si hay incidencias, debe existir una ruta para corregir y volver a validar. Un PDF abandonado en una carpeta no es automatización; es almacenamiento.
IfcOpenShell merece la pena cuando convierte una decisión concreta en un proceso repetible. No sustituye el acuerdo sobre los datos ni el criterio de quien revisa el modelo. Nos da algo más útil: una forma de hacer explícita esa lógica, probarla y mejorarla sin revisar a mano la misma tabla por enésima vez.
Respuestas