Oldie but (apparently) a goodie today. While I’ve linked to some isolated HTML for this project, I’ve never actually blogged about my data visualization final project from last year. This project looked at using treemapping, a fairly common technique for comparing relative sizes in a hierarchical organization, as a way to visualize dynamically the program requirements for an architectural project. I’m reposting this now for two reasons:
1. I am actually using this tool at work for program analysis at the beginning of projects, and it’s turning out to have some utility, and
2. A co-worker pointed out that a NASA spinoff is actually selling a space planning consultancy with a basis in treemapping. The presentation is undeniably impressive but also to me a bit myopic – so much time is spent talking about optimization methods without any discussion of whether the set goals are even appropriate. It seems a bit silly that you would discuss reorganizing an entire campus without the possibility of changing any interior walls, for example. While the NASA tool does present a fully developed application for space planning, it ends up presenting as many new issues as it solves, issues that I didn’t even consider below as I hadn’t thought about this method used to reallocate existing space. It seems like this team needs to have a discussion with some CAFM people to figure out the true parameters of controlling space.
In any case, my research is presented below.
If you want to play with a demo, the applet is (as always) on my dropbox.
Introduction:
This project started as an attempt to use graph visualization to show the implicit room organizations of existing building plans (fig.1). Ultimately, the project shifted to treemapping architectural program documents, for reasons that will be explained below. In architectural language, the word “program” is used to describe the intended uses and requirements of a space. Thus a program document generally includes a list of required spaces and space groups, as well as details such as area, capacity, adjacency, and other general requirements. Preset architectural program documents are common for complex building types, particularly in civic projects or programs that are highly functional. For this project I have chosen to focus on a typical middle school program document, as the information is publicly available and relatively complex.
When architects are given this document, a common first step is to draw out all of the spaces required to gain an understanding of the relative sizes of not only the rooms, but the program areas and organization. This is often done manually, and often ends up such a large document that it is difficult to comprehend it in it’s totality, or remove a lot of the detail.(fig.2) The goal of this visualization was to come up a way of automating this process, to allow someone who is unacquainted with the document to gain a quick but rich understanding of the size and organization of the spaces. I also added functionality to allow the user to make notes embedded in the document, for incorporation into the project later.
Given that a plan drawing already visualizes all of the information that would be in the graph, it seemed redundant to work on my original proposal. Since program documents can be confusing and are inherently non-visual, working from the “other end” with the raw program document seemed to be more useful.
 |
| Project Proposal |
 |
| Seattle Library Program Diagram |
Related Work / History
Topological models of architecture have a relatively long history – one early example is work by Philip Steadman at Cambridge University in 1973 on “Graph-Theoric Representation of Architectural Arrangement.”(fig.3). This work attempted to make a “library” of all possible topological arrangements in a plan diagram for a certain number of rooms. Also of note in the same program in 1972 was the work of Philip Tabor and Tom Willoughby on walk distance optimization, using a combination of graph theory and a traveling salesman algorithm. This research ultimately concluded that quantifiably optimized architectural solutions were not possible.
With the resurgence of computational design in the last decade, there have been more attempts to visualize room organization (although most designers work on issues in geometry rather than topology). The most notable attempt recently was by the Aedas R&D team (fig.4) which used a three-dimensional graph layout to show the relationships between program areas.
 |
| Philip Steadman Adjacency Graph |
 |
| AEDAS R&D Adjacency Graph Program |
 |
| Tabor/Willoughby Topology Diagram |
Approach
Ultimately, research into precedent and methods convinced me to shift my approach from graph visualization to treemapping. There are many examples of program adjacency diagrams in architecture, and they have a lot of use. However, generally they appear later in the design process, as a method of design itself. Program documents have much more information about the hierarchical grouping of spaces than actual adjacency; indeed, room numbering is treelike in nature, using dot notation (e.g. “Room 1.23.4”). Where adjacency is required and noted, it can be of different types – a circulatory connection, a visual connection, or simply a requirement to be physically near. This complicates the process of visualizing these requirements. Circulation space is also not typically indicated in these projects, and thus is difficult to visualize properly – in the Aedas example above, there are large “hallway” bubbles that would not have been in any program document.
Finally, I wanted to choose a visualization method that was the least suggestive spatially, to keep from the diagram being to suggestive of the final design. Architects have a history of “building the diagram” with mixed results. The best projects often purposefully mix or subvert adjacency requirements to add a sense of community or give a more engaging spatial layout. Thus, I wanted to make it clear from the outset that this tool was not a “building designer” but instead a simple method for exploring program requirements.
Data
The data chosen for this project was the middle school space requirements for the Clark County School District in tNevada. This particular document was chosen as it was easily accessible on the internet, and contained enough detail and depth to make the visualization interesting. It was also in a tabular format, within a pdf document, that I could begin working on immediately. The information I chose to work with was the space number, name, capacity, area, and quantity. The data was converted to a tab-separated value (.tsv) file to work with Processing, and also required some cleaning, primarily to change the numbering to make it more logically treelike (a space labeled 1.21.1 was changed to 1.2.1.1). This was done simply using regular expressions in a text editor (Notepad++) the .tsv file. Some errors, like misnumbered or missing parent spaces, were also corrected.
Implementation
This project was built in the Processing language, starting with the treemapping example provided by Ben Fry. This provided both the treemapping algorithm, an open source java library provided by Martin Wattenberg and HCIL, as well as some functions to help animate transitions. I also used the “Table.pde” .tsv reader and writer file that was provided for an earlier CS171 project. All of the code except for the libraries above underwent significant modification, both to the visual appearance of the map as well as the interface and functionality. The actual layout algorithm was changed to a “Squarified” layout that reduced the number of thin rectangles in the map. A detail window was also added to the right hand of the map to show the layout in outline format as well as some detail for the space on the mouse over. The labeling method was made more sophisticated, and a visualization of occupant capacity was added. Finally, the “controlP5” Processing library was used to add some notation functionality to allow the user to add notes to the document.
Results
The peer evaluations received confirmed some of my previous decisions – there was some concern that the visualization of existing plans simply duplicated and simplified the information rather than showing something new.
The system as designed works with the provided “data.tsv” file, although there is some file-selection functionality that has been commented out, as it did not work on the applet version. The file is intially displayed at the first level of detail, with the mouseover displaying some additional information to the right. Immediate child groups of the level you are at are shown with larger labels at the bottom of the space.
Clicking within the spaces opens them to reveal the child groups and rooms within. Each level down the group or room gets lighter, suggesting its depth in the tree. Area and capacity (for rooms) is also shown if it fits – capacity by drawing a darker box within the room itself. Finally, small white tags appear at the upper right hand corner of a group or room if there is a note added. The outline view at the right hand size shows a list of the groups and rooms that are visible. The mouseouver shows information about the lowest level space or room that is visible.
After the entire depth of a space has been revealed (down to room level), an additional click will zoom the treemap onto the next level down in that area. Repeated clicking will allow zooming to the lowest group level in the map. Right clicking zooms back out to parent groups, and when at the top level will “close” the groups again, hiding child groups and rooms.
Finally, hitting the enter key while hovering over a space will open a text box that will allow a user to add a note to that space. Adding a note puts a tag on the space, and a mouseover will show the note as well. Currently the model does not save the notes back to the .tsv file, however, due the the restrictions of the web applet format (the functionality exists but has been commented out).
Discussion
The strengths of this approach are the ease of interaction, and the immediacy of understanding – it gives a very quick overview of the area and ownership hierarchy in a program document. The animation of the zooming invites the user to drill down and look at certain program areas with more detail.
This approach is, however, can be seen as reductionist, as it eliminates adjacency (beyond ownership) from the diagram. The map is not user-editable, so awkward layouts cannot be changed or adjacency ideas explored. After doing this project I understand well the advantages and disadvantages of treemapping, and have been able to explore in detail the goals and implications of diagramming and visualizing architectural data early in the design process.
Future implementation goals would involve a more rich set of interactions with the data set, such as allowing modification of the size or capacity of spaces. The idea situation would be a hybrid treemap / graph layout which would allow the user to move between visualization and explore multiple dimensions of the implicit data, as well as adding linkages or spaces on the fly.
References
Ben Fry’s treemapping resource : http://www.benfry.com/writing/treemap/
Aedas R&D: http://aedasresearch.com/
History of graph theory in early computational design:
Keller, S. (2006) Fenland tech: architectural science in postwar Cambridge. Grey Room, 23:40-65.
Keller, S. (2005) Architectural Theory at the University of Cambridge, 1960-75. PhD thesis, Harvard University.
workhuman 