Validar IFC con Python: convierte tus reglas BIM en pruebas
La hoja de requisitos decía que todas las puertas de recorridos protegidos debían informar resistencia al fuego, clasificación y código. Sonaba suficientemente claro hasta que el IFC del colegio llegó con tres nombres de propiedad, valores como «EI2 60-C5», «60 minutos» y varias puertas modeladas como elementos genéricos. La revisión manual encontró problemas, pero nadie podía asegurar que hubiese recorrido las 438 puertas ni repetir exactamente el criterio en la siguiente entrega.
Validar IFC con Python sirve para convertir requisitos repetibles en pruebas que produzcan evidencia. No convierte una frase ambigua en una norma ni decide si el edificio cumple por completo. El código puede abrir el archivo, seleccionar entidades, consultar propiedades y registrar resultados. El trabajo difícil sigue siendo definir qué comprobar, sobre qué objetos y qué significa un fallo.
Tabla de contenidos
La regla se escribió antes que el bucle
El equipo empezó describiendo un caso concreto: las puertas incluidas en recorridos protegidos debían tener un identificador, una clasificación acordada y una prestación de resistencia al fuego expresada según un catálogo. La condición «incluidas en recorridos protegidos» necesitaba una fuente: propiedad del espacio, clasificación de la puerta o relación mantenida en el modelo.
Se prepararon ejemplos correctos, incorrectos y dudosos. Una puerta sin valor era un fallo claro. Un valor con formato distinto podía requerir normalización. Una puerta entre dos espacios, uno protegido y otro no, necesitaba una decisión de alcance. Estas situaciones se resolvieron con el responsable técnico antes de programar.
La regla quedó compuesta por aplicabilidad, propiedad, condición, severidad y mensaje. Esa estructura permitió discutirla sin mirar Python. Si el requisito cambiaba, el equipo sabía qué parte estaba modificando.
IfcOpenShell abrió el modelo, pero no explicó su intención
El script cargó el IFC con IfcOpenShell y leyó esquema, cabecera y entidades. Esta primera etapa detectaba archivos que no podían interpretarse o que no correspondían a la versión esperada. Después seleccionaba puertas y reunía identificador, tipo, contención espacial y conjuntos de propiedades.
El acceso era técnico, no semántico por arte de magia. La biblioteca podía devolver un valor; el equipo debía saber en qué conjunto buscarlo y cómo se había mapeado desde la herramienta de autor. Si una puerta aparecía como IfcBuildingElementProxy, el problema podía estar en la exportación, no en la consulta.
Por eso el resultado conservaba entidad real y propiedades disponibles. Cuando una regla no podía aplicarse por clasificación incorrecta, no informaba simplemente «valor vacío». Indicaba que el objeto no había llegado como la entidad prevista.
La tabla dejó de ser una lista de deseos
Los requisitos se organizaron en CSV con columnas controladas: código, entidad, propiedad, conjunto, operador, valor esperado, severidad y versión. Antes de evaluar el IFC, Python validaba la tabla. Una columna mal escrita o un operador desconocido bloqueaban la ejecución.
El CSV facilitaba que perfiles BIM revisasen catálogos sin editar código, pero no permitía expresar cualquier lógica. Las reglas con relaciones complejas o cálculos necesitaban módulos específicos. El equipo evitó construir un pequeño lenguaje de programación dentro de Excel, una evolución natural que suele terminar reinventando Python con celdas de colores.
Cada versión de requisitos se guardaba junto con el informe. Así podía saberse qué condiciones había superado una entrega, incluso si el catálogo cambiaba meses después.
Los resultados conservaron suficiente contexto para corregir
El validador devolvía una fila por regla y objeto: archivo, versión, identificador IFC, entidad, propiedad, valor encontrado, condición, estado y mensaje. Cuando era posible, añadía planta o espacio para localizar el elemento.
Los estados distinguían correcto, fallo, advertencia, no aplicable y no evaluable. «No evaluable» era importante: si faltaba la información que determinaba el alcance, el script no fingía que la puerta cumplía. Mostraba por qué no podía decidir.
El informe agrupaba por regla y severidad, pero conservaba detalle. Una cifra resumida ayudaba a priorizar; la evidencia permitía volver al modelo de origen. La validación no corregía el IFC ni rellenaba valores para mejorar el porcentaje.
La normalización se utilizó con límites visibles
Los valores de resistencia llegaban con variaciones de mayúsculas, espacios y guiones. Algunas podían normalizarse sin cambiar significado. Otras representaban clasificaciones diferentes. El equipo creó un mapeo aprobado y registró valor original y normalizado.
Cuando el texto no coincidía con el catálogo, el resultado era una advertencia o un fallo según el requisito. No se aplicó una similitud difusa para adivinar prestaciones de seguridad. Una coincidencia probable puede ayudar a revisar nombres; no debe inventar el comportamiento de una puerta.
Los catálogos tenían propietario y versión. Cambiarlos activaba pruebas sobre ejemplos. Esta disciplina impedía que una corrección rápida en CSV alterase silenciosamente cientos de resultados.
Las reglas de proyecto y la normativa tomaron caminos distintos
Comprobar que una puerta tenga una propiedad es una validación de información. Determinar si la resistencia exigida es suficiente para su situación puede requerir uso, sectorización, recorrido y normativa aplicable. El script podía preparar esos datos y aplicar condiciones formalizadas, pero el responsable debía validar que la interpretación normativa fuese correcta.
Las reglas de nomenclatura, parámetros obligatorios o clasificación pertenecían al intercambio del proyecto. Las comprobaciones normativas citaban fuente, versión y alcance. No se mezclaron en un único porcentaje de «cumplimiento» que sugiriese una certificación total.
Cuando una condición no podía formalizarse con fiabilidad, quedaba como revisión profesional. Automatizar una parte no hacía desaparecer el resto; hacía visible dónde empezaba el juicio.
IDS evitó escribir Python para cada requisito simple
Las condiciones de presencia y valores permitidos podían expresarse mediante IDS cuando encajaban con su alcance. Esto facilitaba intercambiar requisitos y utilizar validadores compatibles sin mantener código específico para todo.
Python seguía aportando orquestación, informes, comparaciones y reglas que necesitaban contexto adicional. El equipo no convirtió el lenguaje en requisito de prestigio. Si un estándar declarativo resolvía la comprobación y otras herramientas podían leerlo, era una ventaja.
Se compararon resultados entre el validador IDS y las reglas Python sobre modelos conocidos. Las discrepancias ayudaban a descubrir diferencias de aplicabilidad o interpretación. La duplicación temporal servía para validar la migración, no para mantener dos verdades indefinidamente.
Las pruebas incluyeron archivos desagradables
Se crearon IFC mínimos con una puerta correcta, otra sin propiedad, un valor inválido, entidad equivocada y relación espacial ausente. Cada archivo tenía resultados esperados. También se utilizó una copia anonimizada de una entrega real.
Las funciones que extraían propiedades y evaluaban operadores tenían pruebas separadas. La integración abría archivos y comprobaba informes completos. Actualizar IfcOpenShell, el esquema soportado o la configuración ejecutaba la batería.
Los errores del propio validador se distinguían de los fallos del modelo. Si Python no podía procesar una entidad, la ejecución no presentaba el resto como aprobado. Un control de calidad que falla en silencio es una máquina de confianza mal colocada.
El rendimiento se trabajó después de obtener respuestas correctas
La primera versión recorría el modelo varias veces por regla. Funcionaba en ejemplos y se volvía lenta en archivos grandes. El equipo indexó entidades y propiedades una vez, agrupó reglas por aplicabilidad y evitó abrir repetidamente el archivo.
También midió memoria y tiempo por etapa. La optimización conservó los mismos resultados sobre los modelos de prueba. Procesar más rápido no justificaba saltarse relaciones o ignorar objetos difíciles.
En lotes, cada archivo se aislaba. Un IFC corrupto no impedía revisar los demás, pero el resumen mostraba la ejecución incompleta. Los trabajos podían repetirse de forma idempotente con la misma versión de reglas.
La comparación entre entregas mostró regresiones
La segunda versión del colegio corrigió muchas puertas, pero una nueva configuración de exportación cambió varios conjuntos de propiedades. El validador detectó que reglas antes evaluables pasaban a no encontrar datos.
El informe comparaba fallos resueltos, persistentes y nuevos. Los identificadores ayudaban cuando permanecían estables; cuando cambiaban masivamente, se analizaba la exportación antes de interpretar la diferencia como modificación del proyecto.
Esta comparación permitió probar no solo el modelo, sino el flujo de producción. Una corrección en Revit debía sobrevivir al mapeo, la exportación y la lectura IFC.
La ejecución automática no eliminó el gate humano
El validador se integró antes de compartir la entrega. Los bloqueos claros impedían publicar; las advertencias necesitaban revisión. Las excepciones se registraban con responsable y alcance.
El equipo revisaba tendencias y muestras, especialmente en reglas nuevas. Una tasa alta de falsos positivos llevaba a ajustar la condición. No se culpaba a los autores por un requisito que la máquina interpretaba mal.
La publicación guardaba archivo, hash, regla, versión del validador e informe. Así el resultado podía reproducirse. Ejecutar Python cada noche era útil; saber exactamente qué ejecutó era imprescindible.
Cuándo una revisión manual sigue siendo mejor
Una condición que ocurre una vez, depende de intención espacial y no puede expresarse con estabilidad quizá no merece código. El validador puede preparar objetos candidatos, pero una persona revisa el caso.
También hay proyectos pequeños donde configurar catálogos y automatización cuesta más que una comprobación acotada. El valor aparece con volumen, repetición y necesidad de trazabilidad. La herramienta debe responder al proceso, no a las ganas de programar.
Python tampoco sustituye validadores oficiales de esquema ni documentación del estándar. Conviene combinar herramientas según la pregunta y citar la fuente de cada requisito.
Una prueba útil dice exactamente qué ha demostrado
Al final, el colegio no recibió un sello genérico de «IFC correcto». Recibió evidencia: archivo interpretable, reglas de información ejecutadas, fallos y excepciones, junto con revisiones técnicas que quedaban fuera del código.
Validar IFC con Python consiste en transformar requisitos claros en evaluaciones reproducibles. Define aplicabilidad, conserva contexto, prueba casos adversos y separa datos de normativa. Después integra el resultado en una decisión editorial o técnica, no en una carrera por conseguir el cien por cien.
Si el informe marca todo verde tras tardar dos segundos en revisar un hospital, no celebres todavía. Puede que hayas construido el validador más rápido del mundo o, con más probabilidad, una regla que no aplica a nada.
Respuestas