Python para arquitectos: automatiza una decisión de diseño, no solo una tarea
Imagina que estás estudiando la distribución de una pequeña escuela. Tienes seis aulas, un límite de superficie, una proporción razonable y recorridos que no deberían crecer sin control. Puedes dibujar tres opciones, medirlas y compararlas. La conversación se complica cuando aparecen quince variantes más y cada cambio obliga a rehacer la misma tabla.
Ese es un buen lugar para hablar de Python para arquitectos. Permite recoger las reglas que ya estás utilizando, aplicarlas de forma consistente y devolver información con la que comparar alternativas. La herramienta no diseña la escuela ni convierte una decisión discutible en objetiva; ayuda a que sepamos qué estamos comparando.
Vamos a mantener este encargo sobre la mesa. Seguiremos una decisión desde la frase inicial hasta un pequeño proceso que el equipo pueda revisar. Por el camino aparecerá una cuestión menos vistosa que el código y bastante más importante: cuándo merece la pena conservarlo después de la entrega.
Tabla de contenidos
Antes del código hay una conversación bastante incómoda
La petición inicial podría ser “busca una distribución equilibrada para seis aulas”. Un arquitecto entiende la intención, pero un programa no sabe qué significa equilibrada. ¿Superficies parecidas? ¿Buena iluminación? ¿Recorridos cortos? ¿La posibilidad de unir dos aulas? Bajar esa palabra a criterios obliga a descubrir cuántas decisiones estaban escondidas dentro de una frase aparentemente clara.
Para empezar, el equipo podría acordar tres aspectos calculables: cada aula debe mantenerse dentro de un intervalo de superficie, ninguna puede superar cierta proporción entre ancho y fondo, y la suma de recorridos desde el acceso servirá para comparar opciones. Quedan fuera la orientación, la relación con el patio, la estructura y buena parte de la calidad espacial. No pasa nada. Reconocer lo que el cálculo no representa resulta mucho más honesto que bautizar una fórmula como “calidad de diseño”.
Después hay que localizar los datos. Superficie, dimensiones, acceso e identificador pueden venir de Revit, IFC, Rhino o una hoja de cálculo. Una tabla es cómoda, aunque quizá ya esté separada del último cambio del modelo. La API de Revit mantiene el vínculo con el proyecto, pero introduce su propio contexto. Un IFC permite trabajar fuera del software de autoría y obliga a entender cómo se exportó la información.
En nuestro ejemplo, cada aula conservará un identificador y el origen de sus valores. Si falta una dimensión o no podemos localizar el acceso, el caso quedará como “no evaluable”. Sustituir el dato por cero para que la operación termine produciría un informe impecable y una comparación absurda. Los huecos de información también dicen algo sobre el proyecto.
Una regla pequeña pone a prueba todo el planteamiento
Podemos comenzar calculando la proporción del aula. No hace falta conectar todavía el modelo completo. Unos pocos ejemplos conocidos sirven para comprobar si hemos expresado bien la idea.
def revisar_aula(aula):
ancho = aula.get("ancho")
fondo = aula.get("fondo")
if not ancho or not fondo:
return {"estado": "no_evaluable", "motivo": "faltan dimensiones"}
proporcion = max(ancho, fondo) / min(ancho, fondo)
return {
"estado": "evaluada",
"proporcion": round(proporcion, 2)
}La función calcula una relación y explica cuándo no ha podido hacerlo. Todavía no decide si el aula es buena. El umbral aceptable llegará del proyecto y se combinará con otras variables. Dar al primer número el rango de veredicto porque podemos colorearlo en verde es una tentación muy propia del diseño computacional.
Probaríamos una habitación casi cuadrada, otra muy alargada y otra sin dimensiones. Después miraríamos las tres en planta. Si el cálculo contradice nuestra lectura, el desacuerdo puede estar en la regla, en los datos o en un aspecto que aún no hemos representado. Cualquiera de esas respuestas ayuda más que seguir generando variantes.
Cuando entran superficie y recorrido, la puntuación deja de ser inocente
Superada la primera prueba, añadimos superficie y distancia desde el acceso. Ya tenemos tres indicadores por alternativa. Sumarlos con pesos parece el paso natural: una cifra permite ordenar rápidamente todas las opciones. También puede esconder que un aula con un recorrido desastroso queda bien clasificada porque su superficie es perfecta.
En una fase temprana preferiría una ficha de comparación. Mostraría condiciones cumplidas, advertencias y valores, manteniendo visibles las compensaciones. El equipo puede descartar alternativas inviables y estudiar las restantes. Si los criterios maduran y existe una razón para agregarlos, habrá tiempo de definir pesos; empezar por ellos suele vestir de precisión una conversación que todavía no la tiene.
Esta decisión cambia también el papel de Python. El programa calcula sin cansarse y mantiene el mismo criterio entre variantes. Nosotros seguimos interpretando las consecuencias. En la escuela, el script puede señalar que la opción C reduce recorridos pero alarga dos aulas. La planta explica si esa concesión es aceptable.
Ese ida y vuelta evita que el análisis se convierta en una competición de puntuaciones. La alternativa con el número más alto no “gana”; llega a la mesa con sus ventajas y problemas mejor descritos. La automatización ha reducido trabajo mecánico sin fingir que la arquitectura cabe entera en un diccionario.
Python puede vivir en varios sitios, y eso cambia la herramienta
Si la geometría se desarrolla en Grasshopper o Dynamo, la programación visual puede mantener las relaciones a la vista y Python concentrar una evaluación difícil de expresar con nodos. Si las aulas ya son espacios de Revit, un entorno con acceso a su API permite leer parámetros y devolver resultados al modelo. Para una entrega IFC, IfcOpenShell puede consultar espacios y propiedades fuera de la aplicación de autoría.
| Entorno | Encaja en nuestro ejemplo cuando | La deuda aparece en |
|---|---|---|
| Excel | Comparamos una tabla pequeña y la regla es transparente. | Copias, versiones y vínculo perdido con el modelo. |
| Dynamo o Grasshopper | La geometría y las relaciones visuales forman parte de la exploración. | Grafos grandes, paquetes y lógica difícil de probar. |
| Python | La evaluación reúne varias condiciones y queremos reutilizarla. | Entorno, pruebas, documentación y mantenimiento. |
| Aplicación propia | Muchas personas necesitan un flujo estable y controlado. | Instalación, soporte y evolución entre versiones. |
Para seis aulas y una decisión puntual, una hoja bien preparada puede ganar por goleada. Python cobra sentido si la evaluación se repite, cambia de escala o necesita conectarse con datos que ya viven en otros sistemas. Elegir la fila más técnica solo garantiza una cosa: que tendremos más tecnología.
El prototipo descubre todo lo que su autor daba por supuesto
Nuestro script ya puede leer opciones y generar una comparación. Mientras lo ejecuta quien lo ha escrito, el nombre del archivo, las unidades y el significado de cada columna parecen evidentes. La primera vez que lo utiliza otra persona dejan de serlo todos a la vez. Es una prueba de calidad muy eficaz y ligeramente humillante.
Compartirlo exige validar entradas y registrar qué versión de las reglas se aplicó. Prepararíamos casos pequeños: una alternativa válida, otra fuera de superficie, una sin acceso y una con identificadores duplicados. Si una modificación cambia esos resultados, queremos enterarnos antes de abrir el modelo de entrega.
La interfaz puede seguir siendo modesta. Una configuración legible y un informe claro aportan más que una ventana brillante alrededor de un proceso opaco. Solo cuando el uso sea frecuente tendría sentido invertir en una integración más cuidada.
Entonces cambia el encargo o aparece un aula especializada. Añadir una excepción puede ser razonable, siempre que represente una categoría estable. Si cada proyecto incorpora cinco casos que nunca vuelven a utilizarse, el script termina describiendo la biografía del estudio en una sucesión de condiciones.
Formatos y herramientas también evolucionan. Una columna se renombra, una API cambia o una exportación IFC coloca las propiedades de otra manera. Los archivos de prueba ayudan a descubrirlo. Y si preparar datos, revisar avisos y mantener el proceso acaba costando más que estudiar directamente las opciones, habremos obtenido una conclusión útil: este problema no compensa automatizarlo todavía.
Aprender Python con un problema que puedas reconocer
Para construir este ejemplo bastan al principio listas, diccionarios, condiciones y funciones. Aprenderlos con superficies y recorridos resulta más natural que hacerlo con ejercicios ajenos a tu trabajo. Después se conecta la lógica con el entorno real, primero leyendo información y generando una salida revisable.
El siguiente paso puede ser una acción pequeña y reversible, manteniendo separadas la regla, la integración y la presentación. Acceder a una API abre posibilidades, pero una herramienta fiable también necesita pruebas, mensajes y límites. Copiar un fragmento que funciona una vez enseña menos que reconstruir una versión mínima y explicar por qué rechaza un dato incompleto.
La escuela sigue necesitando arquitectos
Al final del recorrido tenemos reglas discutibles, datos con procedencia, una evaluación repetible y un informe que mantiene visibles las excepciones. El equipo puede comparar alternativas sin rehacer cada cálculo y continuar mirando la planta, que sigue siendo donde muchas consecuencias se vuelven evidentes.
Ahí está el valor de Python para arquitectos: hace explícita una parte del criterio y permite probar qué ocurre al cambiar las entradas. Lo que todavía no sabemos formular permanece en la conversación, sin recibir una puntuación inventada para que el proceso parezca completo.
Ante la próxima tarea repetida, empezaría escribiendo qué decisión contiene y cómo reconoceríamos un resultado dudoso. Cuando esa explicación se mantenga estable, Python tendrá un problema concreto al que agarrarse. Y nosotros sabremos por qué merece la pena conservar el script después de cerrar el proyecto.
Respuestas