work mostly play

CS171 Final Project – Treemapping Architectural Program Documents

Treemapping a Middle School

It seems like all I do here is post Processing applets. Well, here's another one. This is the final project for my CS visualizations class, an attempt to use treemapping to explore architectural program documents. The full project presentation is here, which includes some background and discussion of the goals and implementation.

I started out thinking I was going to make an adjacency diagram tool, that used graph representation to explore the topology of an architectural program. This sort of idea has been explored fairly thoroughly by Aedas R&D as well as by a BVN Usyd team. However, after some research and test implementation I changed my approach to treemapping, which drops adjacency in favor of nested grouping. The reasons behind this were based not only on an interpretation of the data at hand, but also on the relationship between diagrams and built work in architecture and a desire to make something that was not formally suggestive.

Graph representation has at least a 50 year history computational design, with the initial apotheosis occurring in the mid 1970's at Cambridge University, in research labs aimed primarily at optimizing architecture for walking distances. This was part of a larger search for architectural problems that had objective solutions, to create a school of architecture that had a solid scientific basis. While the work done by the CU researchers was rigorous and interesting, ultimately walking distance faded as an area of research, partially because its optimal organizations often flew in the face of other architectural requirements (such as constructability) but also because the issue of adjacency was more easily solved through telephone and intercom systems. For a more in-depth exploration of this history, please read the "Fenland Tech" article by Sean Keller in the MIT press, or better yet his GSD thesis from a few years ago.

Compounding this historical warning flag was the fact that producing graph layouts of existing structures is actually a lossy, reductionist way of showing floor plan information - one early reviewer called the idea "idempotent." There is also some inherent flaws in the method, such as how to represent circulation space, particularly looped hallways. The topology of a building's room layout is invariably more complicated than a simple graph layout can really indicate, and usually some important detail is lost in the conversion. The BVN blog has a great post on the limitations of adjacency graphs.

I looked instead more closely at visualizing nonspatial data-- that is, the horrifically boring, overly detailed program requirement documents that get handed over to architects on pretty much any large scale project. I concentrated in particular on public school documentation, as they are inextricably linked to public policy and funding, and the building type is overdue for some re-imagination. On review, it became quickly clear that adjacency doesn't really play a strong part in program requirements, and where it is mentioned, relationships are unclear (adjacency can be defined by nearness, visibility, connectedness, etc). I chose instead to take advantage of the basic structure of the document - as a series of nested groups - and visualize this ownership hierarchy over some imagined or invented connectivity. Doing this also avoided a major pitfall of program visualization, which is that bubble diagrams or adjacency graphs can be too suggestive of a final form, leading to the architect "building the diagram." This method takes maximum advantage of the spatial encoding of data while being as neutral to the idea of a building's form as possible.

In the end, I'm not that enamored with the tool I've created, but the above insight makes the entire process worthwhile.