Posted by on May 20, 2015 in Python | No Comments


Want to try Python and don’t want to go through the hassle of installing it? Want to test a script and you’re away from your laptop? is a handy web app that will let you run Python scripts in your browser. It makes working with Python much, much more manageable and a breeze to use when you’re on the road.

From ::Wired

Morphocode’s Urban Circulation Data

Posted by on Jul 14, 2014 in Apps, computational ecologies, data mapping | No Comments

Hong Kong – Walking
Hong Kong – Cycling
Hong Kong – Running
Hong Kong – Vehicular Transport

Creators of the GH plugin Rabbit Morphocode have used Humanco Inc’s app Human to describe circulation patterns in 30 cities worldwide. The circulation is broken down by vehicle, giving interesting analysis about how people move through different metropolises. The imagery is remarkably beautiful and insightful… I would not have expected for Montreal to be #2 on this list for car traffic.

More here.

Edit: I incorrectly reported Human as having been created by Morphocode, it was created by Humanco Inc. Thanks @morphocode!


Posted by on Jul 10, 2014 in Apps, Augmented Reality | No Comments

I posted about Heavy and PublicAdCampaign collaboration Re+Public a few months ago, now they’ve released the beta for their app NO AD and are planning on launching an augmented reality art campaign in the NYC subways in September.

With the nascent AR hardware like Google Glass, Vuzix, and the recently acquired by Microsoft Osterhout becoming more prevalent, strategies for integration of the digital into the virtual will become more relevant and pervasive. Re+Public’s approach of replacing gaudy advertisement with curated art is a provocation at the moment, but what happens to advertising if you can program your Corning Automotive Windshield to replace every billboard with a Stephen Glassman Greenboard? It’s a little simplistic to expect a seven billon dollar industry to simply cave, but what would be the outdoor advertising’s response to their version of TiVo? How do you do product placement in the physical world?

Slight – Anonymous Social Networking

Posted by on Jul 9, 2014 in Apps | No Comments

screenshot20140522at2.55.39pm copy
John Nash’s Slight is a geo-located, anonymous chat app that ties metadata to location instead of user identity. Rather than following a specific named source, the app allows users to find conversations relative to a specific place. Slight uses a map interface to show where conversations are occurring and allows users to interface with a specific dialogue.

Slight is an interesting development, a proto-web 3.0 app in the same vein of Foursquare. While the user is not completely tethered to their location, the app initially organizes conversations relative to location and conversations cannot be started except within a user’s specific location. This blend of inflexibility / flexibility towards geo-location is a compelling balance, and could serve as a model of how the virtual and digital realms interact moving forward.

Read more on Slight here and here.
From Michelle Lane / BREAD.

TT Toolbox for GH

Posted by on Feb 28, 2014 in Grasshopper | No Comments

Engineering behemoths Thornton Tomasetti put out their TT Toolbox GH component early last year, but a student of mine recently shared their new release with me. Their new release builds off of their solid spreadsheet and structural capabilities with an interesting twist- they now can read Google Sheets in real time. This is not just exciting for OpenOffice aficionados, but produces some interesting possibilities due to Google Sheets’ nature of being web-hosted. Nathan Miller has had components with a robust ability to interface with server-based data for a while, but the TT Toolbox’s ability to interface with Google Drive instead of a complex MySQL server opens the door for web-based and remote form generation, as shown below:


Posted by on Feb 26, 2014 in architecture, Grasshopper | No Comments

This is pretty amazing- GENERATOR not only preps GH data for web-viewing, but it also preserves the slider functionality… Pretty amazing stuff. Download here.

Positioning .gpx Information in GH

Posted by on Feb 12, 2014 in data mapping, Grasshopper | 2 Comments

The GPS eXchange file format is a quick and easy way to get geo-located points out of a tracking software such as Strava or MapMyRide. I hadn’t realized that it was in an .xml format until reading Hjörtur Sigurðsson’s blog post on positioning Endomondo information in GH. Sigurðsson doesn’t go into detail about how to develop the script, so I thought I’d play around with it and see how to get .gpx info into the GH environment. This script uses components from gHowl and Elk, feel free to click on any of the images to enlarge.


The first step is to create a link between GH and the .gpx file path. Save the .gpx file you’d like to use somewhere on your machine or server, and then use the File Path module to link the information into GH.


Use gHowl’s Xml Parser module to parse and understand the .xml data.


The .xml data will likely have some metadata at the top of your point list, use the Split Tree module to create a branch without this info. The Split Tree’s splitting input is inclusive, so you want to list the last branch you’d like to remove for the split.


The formatting may change depending on your .gpx source. In this case, the point coordinates were listed as separate items within a branch, so use list items to separate the different coordinates and then merge them back together in a Construct Point module.


Once the points are formatted, follow the same sequence I described in my tutorial on using Elk to Create Maps in Grasshopper. This requires finding a .osm file and SRTM data of the same area that you are mapping. This isn’t an overly elegant solution at the moment, but will allow you to position .gpx information within GH. Good luck!

Metaball Diagrams with Google Earth and gHowl

Posted by on Jul 8, 2013 in data mapping, Grasshopper | 3 Comments

Google Earth presents an intuitive, dynamic platform for understanding spatial context. Combined with a parametric modeler like Grasshopper, Google Earth presents complex datasets relative to geo-positioning in a way that is understandable. Facilitated by GH plugin gHowl, GH meshes and lines can be exported in Google Earth’s .kml format to be viewed by Google Earth or an enabled web browser.

Creating legible geometry for Google Earth is challenging, but one type of geometry I’ve experimented with is GH’s metaballs, which are about as old school as it gets for 3D curvature. Metaballs, as described by Yoda (Greg Lynn), are “defined as a single surface whose contours result from the intersection and assemblage of the multiple internal fields that define it.” (Lynn, Blobs, Journal of Philosophy and the Visual Arts 1995). This aggregation of internal fields can provide an intuitive understanding of various contextual forces relative to the spatial context of a site. While GH metaballs are only curves and not meshes / surfaces you can easily use a delaunay mesh to begin to create a mesh.

This tutorial will walk through the process of creating metaballs from Geo coordinates. I’m using a map I created with Elk that is based off of Open Street Maps info, if you’re interested in doing something similar look here.

Just click on the images below if you’d like to see them in more detail.

Start by positioning your Geo coordinates in GH space through gHowl’s Geo To XYZ module.


Use the output of the Geo to XYZ module as the point input for GH’s Metaball(t) module. There are several options for creating metaballs, I’ve had the best luck with the (t) one. The next step is to set up a series of section planes for the Metaball(t), the number of planes will define the resolution of the metaball. Instead of creating planes, it’s a little bit more familiar / easier to create a series of points in the Z direction. The last input you need is the threshold value, which is a number you want as low as absolutely possible. The trick to this is that you probably still want the flexibility of a slider, but on a city scale metaball you need a number smaller than .001 which is the minimum value a slider allows. The trick here is to multiply two sliders with small values together and use that value to drive the threshold value, you can even use a third or fourth slider if you are using a bigger scale.


Once you’ve created the metaballs, you can use the gHowl KML Out module to create a .kml. Use a path module to set a file path, have the Metaball(t) output feed the G input of the KML Out. Use the KML Style module to set the curve color and use 2 similar GEO and XYZ points that you used in the Geo to XYZ module to Geo reference the output. I’ve had the best luck with setting the Altitude Mode to Absolute, but I’ve really only done this at sea level at this point.


This will create a .kml file that will show your metaball data in Google Earth.


Using Elk to create maps in Grasshopper

Posted by on Jun 20, 2013 in data mapping, Grasshopper | 20 Comments

As far as information synthesis goes, Grasshopper is pretty amazing. A frequent starting point for representing data is with the conventional geographic map, which creating in GH is not always an intuitive process, so I thought I’d create a tutorial on creating a geographic map in GH to begin to map spatial data. The plugins I use in this example are gHowl and Elk. If you follow along with the exercise, feel free to click on the images below to enlarge them.

First, download your vector information from Use OpenStreetMap’s interface to crop to the area you’d like to map, and download an .osm file by selecting the export tab and then OpenStreetMap xml data.


In GH, use Timothy Logan’s Elk to bring the .osm info into GH. Use the File Path module to connect to the P input of the Location module, this identifies the .osm file you’d like to use.


The Location module parses the .osm file and identifies what objects are what. You then need to start connecting the rest of the Elk modules to pull out the different kinds of data- connect the O and X outputs of the Location module to the O and X inputs of any of the other Elk modules (except the topo module) to start building your map.


The points representing the different objects will be organized in different branches, which will allow you to create different geometry from them.


The GenericOSM module is crucial, it allows you to parse any other osm features there aren’t modules for, in this case Buildings. You can find a list of osm features here. You can also use a text editor to open your xml file and see what points are tagged with data. Amenity, Highway, and Railway are all worth exploring- Land Use is particularly interesting. You can also use the V input to parse for subcategories of features and the K output combined with the Text Tag module to label the objects with their metadata. GH3D user Ivor Ip posted a GH attribute list of some of the osm features that you can download here.


This is a workable base for many diagrammatic maps- there’s a lot more data we can add but for now this should give us enough to work with. The next step is creating the ability to position WGS84 coordinates (longitude and latitude information) relative to this information. Use Elk’s sTopo module to use SRTM data to create a topography. First we’ll need to download the right SRTM file, I’ve been using the the WGS84 info from Elk’s Location module to help find the right file from the USGS repository. Be sure to verify that you’re looking at the right data with QGIS or another program- the naming convention can be a little tricky… but once you have your .hgt file, use the File Path again to reference it to the sTopo module.


If you’re interested in creating a 3D topography, flattening the points from the sTopo module and inputting them into a Delaunay Mesh will create a quick and easy mesh. For our purposes, we’re just going to use the points created from the topography as a reference for mapping our coordinates. The goal here is to use gHowl’s Geo To XYZ module to position coordinates relative to our map. Find the first and last points from the sTopo for the P1_XYZ and P2_XYZ inputs, then use the Lo and La outputs of Elk’s Location module to create info for the P1_Geo and P1_Geo inputs.


Now any WGS84 coordinates that are loaded into the Geo to XYZ module will be positioned on our map. This is particularly useful when mapping geotagged information, like tweets or other social media info.

FreelandBuck’s Slipstream Drawings

Posted by on Dec 19, 2012 in architecture, Grasshopper | No Comments







There was a lot of chatter on the web last spring about FreelandBuck’s Slipstream Installation at the Bridge Gallery in NYC. It’s a pretty impressive piece, with over 1000 CNC milled plywood pieces that are aggressively non-orthagonal. One element of the piece that hasn’t gotten as much recognition is the incredible drawings that served as the systemic generator of the installation. On FreelandBuck’s website the drawings are described as:

As part of the Slipstream Installation inspired by Lebbeus Woods’ 2010 ‘Slipstreaming’ drawings, we developed a series of computational representations of flow. These drawings were each potential catalists for the installation suggesting both dynamism and bi-directional interlocking structures. The drawings were elaborated not through the conventions of digital drawing but toward other graffic mediums -charcoal, painting, drafting – opening up more diverse and tactile associations.

Flow, dynamism, and interlocking systems are almost architectural memes at this point, the evidence residing in the inclusion of these terms in most if not all of suckerPUNCH‘s entries, but what is most compelling about the Slipstream drawings is their effectiveness at conveying these concepts. The organization of the linework is remarkably fluid, the geometric arrangement is particularly evocative and the use of color gives a depth and a sense of space that few drawings can. In Orhan Ayyüce’s interview with David Freeland and Brennan Buck on Archinect, FreelandBuck describe a particular spatial interest themselves:

We are still very interested in the values and ambitions of the earlier generation of digital formalists – that space does need not be defined by a stable grid of lines and planes but can be far more dynamic and engaging when defined by curved surfaces, torqued planes and shifting tessellations. So our primary ambition is spatial even if the means are formal.

For FreelandBuck the interest in formal affect isn’t limited to this particular project or even their practice as a whole, but their teaching as well. In the description for Evolving Media on FreelandBuck’s website David Freeland describes the course as:

The drawing, as instrument of the avant garde, has been a significant transmitter of meaning in architecture, not through its faithfulness to translating a message, but in terms of the properties inherent to drawing which are deployed in support of a given ontology. Seeking the qualities inherent to computational drawing- multiplicity, systemiticity, gradation- this class reimagines the drawing in terms of visceral perception, a medium for the creation of a field of effects more atmospheric than Euclidean.

This interest in spatial engagement is at the root of what is especially compelling about the Slipstream Drawings, as they are more than an algorithmic assortment of lines but an attempt and a means to evoke and organize space.