We’re creating a web-based tool for interacting with climate data. The Department of Energy’s EPW files have a consistent format and are publicly available for almost every major city on Earth. This is great for data visualization, so here’s the first step we took: observe and compare parameters from an EPW file for TMY Data.
While there are plenty of robust programs available for environmental simulation of modeled geometry, abstract climate analysis and our interaction with it requires improvement in the AEC industry.
A great tool for early climate study is Climate Consultant, but this is a standalone program which makes it difficult to produce drawings and provide documentation. Another option is Ecotect, but Autodesk absorbed this beloved program and quickly put an end to further releases, vying instead for a limited front-end implementation in other software.
In the Grasshopper community, promising development for data interaction can be found with Ladybug and Dhour. These programs are powerful in that they can use climate data directly with geometry, however many designers are not familiar with Grasshopper for Rhino which creates a potential hurdle.
The interface we’re working on offers customization of graphics through web-based interaction (we’re setting geometry aside and focusing on climate conditions). In the video above, we have a familiar scatter plot with a row of parallel coordinates below. All of these coordinates may get a little confusing, so the below interface is a simpler example which focuses on Seattle’s summer temperature conditions. Remember to be in Firefox or Chrome to get full functionality:
[pageview url=”http://lmnarchitects.com/tech-studio/wp-content/uploads/sites/4/2014/04/Climate/seattle-summer-temps.html” width=”600px” height=”530px” border=”no”]
As is the case with any parametric model, we learn about its properties through interaction. With a flexible interface, we can apply a forensic approach when learning about a given climate. We often compare humidity to temperature and radiation to illuminance, but are there other trends which we have overlooked? How about our intuitive assumptions? Do they align with the raw data? Our aim with this first pass is to provide an easy way to visualize EPW data, identify patterns in parametric relationships, and deduct conclusions on the climate based on visual feedback.
The basic example above reveals some interesting things about Seattle when adjusting some of the viz parameters. By toggling through the X-axis, Y-axis, Radius, and Color display, we get an array of charts as represented below:
Now, this is looking rough and abstract and it may get even more so. While the above was a look at some temperature and humidity values, bear in mind that an EPW file offers 20+ parameters measured at every hour over the course of a typical meteorological year. There’s much more data to be explored. Below is a demonstration of solar values, and this is setup with “date” in the X and “hours” in the Y to create the familiar heat map that we see in various climate visualization software:
[pageview url=”http://lmnarchitects.com/tech-studio/wp-content/uploads/sites/4/2014/04/Climate/seattle-summer-sun.html” width=”600px” height=”530px” border=”no”]
Again, by making basic adjustments in the visibility settings, we can observe transitions between nodes to better understand the data (ie: does a y value move up or down when animating from a temperature trend to a humidity trend?) Some choice examples can be found in the images below:
When using the interface, one starts to understand that the radius and color parameters create significantly more complexity. These settings are optional so the user doesn’t get overwhelmed by four-dimensional data on a two-dimensional canvas.
And speaking of multi-dimensional complexity, many thanks to Kai Chang for his development of the parcoords library for D3JS. This library was essential in the design of this tool. For more on parallel coordinates, check out Kai’s mind-altering presentation from OpenVisConf 2013.
Lastly, we’re ensuring that this interface remains generic for dealing with any range of data. We did some earlier work with optimization solvers and intend to implement an interface similar to this for optimization solvers. In the design for this post, we have parameter values pop-up when the mouse hovers over a target node. It’s possible to turn this functionality into a fully interactive model for each node on a full landscape of optimization. Similarly, we can use a generic tool like this to study trends in occupancy comfort data as well as EMUs (Energy Monitoring Units).
In conclusion, we’re providing the interface for designers to test out on their projects. Click here to access the interface, have fun and let us know if you have any questions or learn something new about your climate.