Making a Christmas card out of tree lot data

The recent months have been full of Christmas card design projects. For this card I was tasked with creating a design based on the same influences I’m grappling with in my personal work, and I went in quite an experimental direction.

My brief to myself was to create something in the same mode as my Central Park series, with data and a pen plotter, but using festive data and themes. We did some brainstorming and the concept that felt most intriguing was to look into data on the various Christmas tree lots that pop up around New York. I associate these lots quite strongly with the holiday season in New York, and having just moved back to the city it seemed like a timely focus.

I began researching and quickly learned more than I ever thought I’d know about Christmas tree lots! It seems that Christmas trees specifically don’t require a permit to vend, which explains their great proliferation in New York around the holidays—but also means there’s not a lot of easily accessible data on them. I found some homegrown maps of lot locations, but simply geographic coordinates isn’t quite enough data to draw something interesting. I decided to make my focus more personal.

To diversify my data types, I turned to Yelp reviews. I took all of the locations they listed as tree lots within the five boroughs, though I had to discard any that weren’t blessed with ratings or reviews (I don’t yet have a great way to illustrate the doubt inherent in a null value). For each of the places I found, I listed geographic longitude and latitude, rating level, and number of reviews.
I then pulled the data into a Processing sketch and wrote code to display each place as a circle at its geographic longitude (y) and latitude (x), scaled based on how many reviews the place got, and with additional circles based on how many stars the place had on Yelp.

Note that you can’t just plot the coordinates directly as they are; the image goes from 0 to 700 on the x-axis, and 0 to 800 on the y-axis; and the coordinates go from 40.6 to 40.9 on the x-axis and -73.9 to -74 on the y-axis (it’s a small geographic area, relatively speaking!). This is where the map(); function in Processing comes in. In some ways, the bulk of the code is actually just adjusting input values to match the vision. (That may in fact describe all code).

I did some test plots of this data with the axidraw, but while the results resembled my Central Park series, I wasn’t sure I could work with them. I wanted to focus on more illustrative, less repetitive elements like the ubiquitous string lights and the wrapped-up trees, and I was concerned the data would get lost amongst the illustration. I decided to go with an image that provided enough visual information to be intriguing, and build the illustrations around that. I went back to Yelp for more information.

I’d saved the link for each listing with its data, so I went back to the listings and fleshed out the spreadsheet with not only the number of reviews, but the word count for each one so I could plot them as lines extending from each site. This form references writing while staying abstract.

Once the code was set, I ran it to render a PDF and then set the axidraw to draw from the vector image.

I used waterproof Micron pen on watercolor paper, so I was able to watercolor directly on the plotted image. I tried various ways of incorporating the essential elements of the Christmas tree lots: the bound trees and the electric-generator lights.


The final image was subtle in a way that was almost mysterious. I focused on the abstract forms of the lights, incorporating some yellow reflections in the pine drawings as well, and the printer reproduced the color wonderfully. I’m impressed with how it came out! The cards are available on Etsy through the holiday season.

Central Park series: data-driven artwork

In this small series, I worked with the axidraw pen plotter and Processing to imagine the new growth happening in early spring in Central Park.

From the warmth of my room, I researched March weather data in Central Park as well as geotagged posts of spring flowers, outsourcing my reference-gathering to the data of others.

I made some simple plots of the weather data using Processing, comparing humidity and temperature by date and plotting the points as small circles.

Cloud cover was additionally represented by adding rings around the circles (the rule was to add one extra ring if cloud cover was between 30% and 60%, two if it was anything over 60%).

With the axidraw, I could then draw the plots accurately and precisely using waterproof artist’s pen directly onto watercolor paper.

I drew lines to create dimensional relationships between the data points, and then “grew” the flowers I’d been researching from home out of the spaces between the data points.

The data formed a “garden” to situate the flowers, and their pattern was dependent on its form, as with the growth anticipated in the season.

The data forms them and gives a structure to their layout, just like the forces represented by that data enable the form of our gardens year over year.

Aleataxonomy series

“Aleataxonomy”, my shorthand from “aleatoric” (created from random action) and “taxonomy” (referring to the classification of the elements I use in drawings), is a recent series based specifically on limiting drawings to randomly-generated numbers of elements in sequence. The project takes on the problem of end condition, or “when is the drawing done”, that I’ve been dealing with since working on series like Schema (one of the first that departed from my historic end condition of “whenever the pattern goes to the edge”). My hypothesis was that even with an artificial end condition, these drawings wouldn’t end up looking unfinished because of the conscious and subconscious aesthetic evaluation I unavoidably engage in as I draw.

Procedurally, I would first figure out what types of patterns would work for this process, break down their individual procedures into steps and ranges, and then write up a script in Processing that would render out random values (within the range) each time it ran.

For some of these processes I made intermediate sketches to determine how I should balance out the ranges of values before I could write the randomizing script.

Once I had a solid idea of the steps and ranges of values, I wrote scripts that would choose a random number from a range for each step and, critically, read the choices back to me in clear step-by-step instructions. Much of “aleatoric” art has to do with physical randomization tools like dice, but since I had access to coding text output and random value generation in Processing, that made it possible to write custom ranges in absolutely whatever value I might want.

Once I had the readout, my task was to follow the instructions to the letter (often using tally marks on scratch paper to record how many of each mark I’d completed).

– Example of a first step. The result of the Processing “dice roll” is at the bottom of the black rectangle below the code. (For those following along at home, the code that requests that printout is println())

– Process for a full drawing

There are many ways I can take this kind of process. One of the options I wanted to pursue was to try using the same exact values to make multiple drawings. Would they be the same, indistinguishable, or somewhere in the middle?

One of the unexpected upshots of this project was learning just how many houses or lines I might be able to draw in a small space without realizing. Even when I was dealing with scales like 6”x8” and large numbers like 150-250, it turns out that’s barely enough “house” marks to look inhabited.

In general, I’m glad I indulged this impetus to take programmatic drawing to a bit of an extreme. It’s another tool I can use to determine when a piece is “finished”; it allowed me to explore aesthetic balances that I might not have chosen to work with before; and in a way it gives me more confidence in the persistence of my artistic style.

Processing sketches

One of my many goals this year has been to learn more about scripting and procedurally generating graphics, for which I’ve been using the language Processing. I don’t have a lot of prior experience with code, though, and that makes things a bit difficult!

It’s a totally different way of thinking. Processes that seem simple enough to me—like drawing a series of city blocks that are different shapes but all have the same width streets between them, for instance—are surprisingly difficult to put into code. And at the same time, graphics that would be difficult or just tiresome for me to execute physically, like filling the screen with parallel lines or drawing the same shape over and over in different places, are particularly simple.
Much of the learning curve has just been differentiating between the different parts of code and learning their names so I can understand instruction, even before I learn the actual functions.

That all said, I’ve been having a pretty good time coming up with little visual programs. Below are some short animations that I’ve made so far. I’m particularly proud of the fact that I came up with and wrote all the code for each one myself. It’s possible to copy others’ code, but I find that that often causes more problems than it solves—and it’s more satisfying to know I coded something from scratch.