Qué se puede hacer con programación BIM: 9 problemas que el código resuelve
Revisar una tabla, renombrar vistas y dejar de copiar parámetros. Nos prometieron el futuro y me han destinado a una columna de Excel; aceptaré el encargo si al menos dejamos de revisarla quinientas veces a mano. Buena parte del valor de programar en BIM aparece en tareas repetidas cuya regla podemos explicar y cuyo resultado podemos comprobar. Vamos a recorrer nueve casos sin fingir que todos necesitan una plataforma ni que escribir más código convierte una mala pregunta en una buena solución.
Podemos usar programación para consultar modelos, transformar datos, preparar documentación y conectar aplicaciones. La herramienta puede ser Dynamo, Python, un complemento o un servicio; antes de elegirla interesa reconocer el problema. Estos nueve casos recorren una entrega hipotética, desde revisar sus datos hasta compartir una herramienta con el equipo. Son posibilidades que necesitan reglas, permisos y comprobaciones concretas, no funciones que cualquier script vaya a resolver por el mero hecho de existir.
Tabla de contenidos
1. Encontrar datos incompletos y devolver algo más que un semáforo
Supón que los equipos de una entrega deben tener un código de activo y una referencia de sistema. Una rutina puede seleccionar el conjunto acordado, leer los datos y separar lo correcto de lo incompleto. La parte delicada comienza antes de leer el primer valor: qué modelos entran, qué categorías cuentan como equipo y qué elementos provisionales están excluidos. Sin eso puedes comprobar mil objetos con enorme precisión y seguir revisando los que no correspondían.
El resultado debería distinguir un dato vacío, un parámetro que no existe y una comprobación que no se ha podido ejecutar. Tampoco es lo mismo una propiedad con espacios que un código reconocido por el catálogo. Guarda la regla y la referencia del elemento junto al valor observado, de modo que alguien pueda localizarlo y decidir la corrección. «Hay 126 errores» exige una investigación; «estos equipos carecen del dato requerido para esta entrega» ya permite actuar. Un contador rojo tiene su público, pero coordinación suele necesitar algo más que decoración dramática.
Empezaría con un informe de lectura y ejemplos conocidos. Incluye un equipo correcto, otro incompleto y uno excluido. Si la herramienta presenta cero problemas porque ha buscado mal el dato, necesita informar de que no pudo evaluar la regla; no ha descubierto un modelo perfecto. Este primer caso enseña una condición que reaparecerá en los demás: el silencio del programa no es una prueba de conformidad.
2. Normalizar nombres sin perder excepciones legítimas
Las vistas pueden seguir una convención basada en disciplina, nivel y propósito. El código puede leer sus datos y proponer nombres coherentes, pero tiene que comprobar qué nombres ya existen y qué ocurrirá cuando dos vistas produzcan el mismo resultado. Quizá una sea una vista de coordinación y otra una variante que no debe confundirse con ella. Quitar el sufijo «copia» sin entender el propósito solo vuelve más presentable una ambigüedad.
Una propuesta de cambios debería mostrar la vista, su nombre actual, el propuesto y cualquier conflicto. Revisa primero esa salida; ejecuta después los cambios confirmados y devuelve un informe. Si existe una excepción de proyecto, regístrala o conviértela en una regla explícita cuando corresponda. No la escondas dentro de un nodo que solo se desconecta los viernes. La tradición oral es fascinante para estudiar culturas; como sistema de configuración de una herramienta resulta incómoda.
Repite la operación sobre la misma muestra. Lo esperable en una normalización bien delimitada es que, una vez aplicada, deje de proponer cambios innecesarios. Si añade otro prefijo en cada ejecución, no tienes una convención de nombres: tienes una colección en expansión. Comprobar esa segunda pasada puede evitar bastante trabajo antes de distribuir la rutina.
3. Preparar vistas y planos que todavía se puedan revisar
Un edificio repetitivo puede necesitar conjuntos de documentación similares por planta o zona. A partir de una tabla o de datos del modelo, una herramienta puede preparar vistas, aplicar configuraciones y colocar parte de la documentación. El ahorro aparece en la secuencia estable; el encuadre que comunica una situación singular puede seguir requiriendo criterio de quien prepara el plano. Que todos los objetos quepan dentro de un rectángulo no demuestra que el plano explique el proyecto.
Define qué partes controla la herramienta: tipo de vista, plantilla, escala cuando proceda, nomenclatura y referencias de la lámina. Después decide si crea, reutiliza u omite cada objeto existente. Sustituir una plantilla de una vista ya preparada es una modificación distinta de reconocer que la vista existe. La documentación de transacciones de Revit ayuda a entender cómo se confirman o descartan cambios cuando trabajas con su API; la integración elegida determina cómo debes utilizar ese contexto.
Empieza generando un plan sobre pocos niveles y comprueba una muestra del resultado. El artículo sobre programación BIM y herramientas mantenibles desarrolla este caso. No des por terminada la operación al contar las vistas creadas: revisa que respondan al uso previsto y que el informe explique cualquier elemento que no pudo producirse.
4. Intercambiar datos con Excel conservando su significado
Una hoja puede recoger códigos de activos o propuestas del cliente que después deben volver al modelo. El problema no consiste únicamente en leer filas. Necesitas relacionar cada una con el objeto correcto y definir qué columnas se pueden editar. Utilizar el orden de la tabla como identidad funcionará hasta que alguien inserte una fila o cambie un filtro; entonces la automatización comenzará a repartir información con una libertad que nadie le había concedido.
Exporta referencias que permitan reconocer el elemento y el contexto del modelo. Al importar, comprueba tipos, unidades y valores permitidos; presenta diferencias entre el dato actual y el propuesto. Decide también qué significa una celda vacía: no tocar, declarar ausencia de información o borrar. Si no lo acuerdas, el código tendrá que elegir una interpretación y la descubriréis al comprobar el resultado.
El modelo puede haber cambiado mientras se revisaba la hoja. Si el elemento ha desaparecido o el valor actual ya difiere del que se exportó, informa del conflicto en lugar de aplicar la columna como si el tiempo se hubiese detenido. Para un primer intercambio limitaría los campos y revisaría cambios antes de escribir. Excel sigue siendo una herramienta útil; convertirlo en un permiso para sobrescribir cualquier parámetro es una decisión bastante más difícil de defender.
5. Consultar IFC y comprobar requisitos concretos
Al recibir un IFC puedes extraer entidades, propiedades y relaciones para revisar información sin recorrer cada objeto manualmente. La documentación de IfcOpenShell muestra consultas y utilidades para acceder a esos datos desde Python. Eso permite construir controles como localizar espacios sin código o equipos sin la propiedad acordada, siempre que definas el esquema y el alcance que admite tu comprobador.
No necesitas generar toda la geometría para responder a una pregunta sobre una propiedad. Separar lectura de datos y procesamiento geométrico puede evitar trabajo innecesario y facilita entender qué está comprobando la herramienta. También necesitas decidir si consultarás valores de ocurrencia, de tipo o ambos según el requisito. Una propiedad que no aparece en el lugar que esperaba tu código no demuestra automáticamente que el proveedor no la haya entregado.
Un archivo válido según su estructura tampoco cumple necesariamente el encargo. El requisito de tu cliente puede pedir información que el esquema no exige en todos los casos. Conserva la regla, el identificador del objeto y el dato observado para que la devolución permita corregir el origen. No entregues solo otra hoja con una columna llamada «mal»: la interoperabilidad ya tiene suficientes dificultades sin que añadamos un acertijo voluntario.
6. Convertir un hallazgo en una incidencia coordinable
Detectar una intersección o un dato incorrecto no decide por sí solo quién tiene que actuar. Puedes enriquecer el hallazgo con modelo, versión, elementos, ubicación y regla, y preparar una incidencia que otra disciplina comprenda. La API BCF de buildingSMART permite intercambiar información de incidencias y puntos de vista entre aplicaciones compatibles; el comportamiento concreto depende de las versiones y funciones que soporte cada una.
Para una colisión necesitarás interpretar tolerancias, fase y exclusiones acordadas. Dos sólidos que se cruzan pueden representar una situación prevista; cien intersecciones en la misma zona pueden ser una única decisión pendiente. Puedes automatizar agrupaciones y propuestas de asignación, pero conviene mostrar de dónde salen. Si falta un responsable o hay dudas con las coordenadas, deja el caso pendiente de revisión en lugar de inventar un valor para completar el formulario.
La siguiente ejecución no debería producir otro centenar de incidencias nuevas para los mismos hallazgos sin explicarlo. Define cómo reconoces un caso existente y cuándo consideras que ha cambiado, se ha resuelto o ya no puede comprobarse. El estado de una incidencia y el resultado de un control pueden estar relacionados sin ser equivalentes. De lo contrario, bastará con perder un objeto en la selección para que el programa anuncie una corrección que nadie ha hecho.
7. Comparar revisiones y señalar lo que merece otra mirada
Cuando llega una nueva versión, puedes comparar inventarios y datos para separar elementos nuevos, eliminados o modificados. Eso permite concentrar parte de la revisión en lo que ha cambiado, pero necesita una correspondencia suficientemente fiable entre los objetos de ambas entregas. Comprueba cómo se conservan sus referencias en tu proceso de autoría y exportación; no presupongas que cualquier identificador resolverá todas las revisiones.
Si la identidad no se conserva, puedes buscar coincidencias mediante otras propiedades, pero deberías distinguirlas de una correspondencia segura. Dos equipos parecidos y próximos no son necesariamente el mismo equipo. Una aproximación puede ayudar al revisor; ocultar su incertidumbre puede llevarle a aceptar un cambio que está comparando objetos distintos. A las máquinas también nos salen las cuentas cuando sumamos cosas equivocadas.
Elige qué cambios importan para el uso: datos de activos, clasificación o propiedades de coordinación, por ejemplo. Un informe de «todo ha cambiado» por una variación irrelevante del exportador no orienta ninguna decisión. Y una comparación de datos no acredita que la geometría sea idéntica si no la has comprobado. Declara qué diferencias detecta tu método y qué revisión sigue correspondiendo a una persona.
8. Conectar aplicaciones sin perder las operaciones por el camino
Una nueva revisión puede iniciar una validación y su resultado actualizar un panel de coordinación. Las APIs permiten consultar o modificar recursos admitidos por una plataforma; los webhooks pueden avisar de eventos soportados, como explica la visión general de Webhooks de Autodesk APS. Después de recibir el aviso, tu aplicación todavía tiene que interpretar el contexto, obtener los datos necesarios y comprobar su autorización.
Aquí aparecen problemas que no resuelve el conocimiento del modelo: eventos repetidos, respuestas tardías, credenciales caducadas y fallos entre dos pasos. Diseña cómo reconocerás una operación ya recibida, cómo consultarás su estado y qué quedará pendiente cuando el destino no responda. Reintentar sin saber si la primera escritura ocurrió puede duplicar incidencias o publicaciones. El historial debería permitir distinguir recibido, en proceso, completado y fallido según tu flujo.
Empieza por una conexión de lectura, un evento concreto y una salida que puedas observar. Añade comprobaciones de recuperación antes de permitir efectos mayores. El conjunto de plataformas conectadas no es una medida del valor de la integración; si no puedes localizar dónde quedó una operación, cinco conectores solo ofrecen cinco lugares donde buscarla. Y cada uno tendrá, por supuesto, su propio panel.
9. Convertir una rutina útil en una herramienta compartida
Los casos anteriores pueden empezar como ayudas personales. Si varias personas empiezan a depender de ellas, cambia lo que debes ofrecer: configuración comprensible, una versión identificada, mensajes útiles y una forma de comprobar el resultado. El script ya forma parte del proceso aunque nadie le haya celebrado una presentación oficial. La responsabilidad no necesita esperar al logotipo.
Puedes separar las reglas de la interfaz y del acceso al modelo para que cada parte se pueda revisar. Mantén muestras pequeñas con casos correctos, incompletos y fuera de alcance; comprueba las integraciones en el entorno donde se utilizarán. Decide quién aprueba un cambio de criterio BIM y quién mantiene el código. Una actualización del software o del requisito puede alterar el resultado sin que el usuario haya hecho nada diferente.
Elige uno de los casos y escribe qué recibe, qué regla aplica y cómo revisarías su primera salida. Si no puedes concretarlo, ahí está el siguiente trabajo; instalar otra biblioteca puede esperar. Un ejercicio pequeño que puedas cambiar por tu cuenta enseña más que una demostración que «automatiza todo». Esa suele automatizar, sobre todo, el paso a la siguiente diapositiva.
Respuestas