The Making of OTTrees

After the city of Ottawa released a data set of 40,000+ individual trees through it’s open data portal I decided to make something that would give a sense of digital awe and wonder to the trees of Ottawa that I feel when walking underneath them in person. On a typical Google map you can see the terrain and the streets; a captured still life of whatever suspended state or season the pictures were taken in. What we can’t see yet is the living breathing mess of life that goes on after the picture happens. I wanted to depict the changing of the seasons, the actual size and color of the trees as the year progresses, as a kind of love letter to my fellow residents or to those who have moved away and miss the city.

I was inspired in part by the gorgeous Census Dotmap and the display human patterns of movement and settlement that arose from the data projections. Another amazing visualization was this mapping of earthquake data to show the impact of a quake through symbols. I teamed up with James DeMond to make OTTrees available for anyone who wishes to see the trees of Ottawa in a new light.


OTTrees is a bird’s eye view of the city, displaying the trees by taking the diameter at breast height (d.b.h.) of the tree and calculating the approximate spread of the tree given it’s species and estimated age. Instead of traditional markers the shapes are drawn as translucent vector symbols onto the map to mimic the tree cover at different times of the year. There is a gray overlay on the map underneath the points; it is there to accentuate the trees and make them stand out from the map. Using the list of tree species I gathered information from Wikipedia and horticulturalist pages to formulate a list of facts for each tree type. I gathered the scientific name, common name, French name, links to the French and English Wikipedia entries, growth rate, growth factor, maximum span, maximum height, leaf persistence, origin, leaf color through the year, allergen potential, d.b.h. at maturity, and if it was fit for human consumption for the 103 different species named in the tree inventory file.

After I had accumulated the information needed we examined the KML file provided by the city to see if there was a way to separate the data into individual files so that the information unique to the species could be added and accessed when needed. Because of the way Google maps handles the drawing of symbol paths we had to convert the files to JSON and massage the data so that the location and addresses of the trees where stored based on species type. We wrote a Java program to massage the data into 103 separate KML files then convert the information stored to JSON files. From there we made arrays in JavaScript to call the names of the species filtered by category to toggle on and display when clicked. Before anything is displayed all the tree points filter through an age sort.

The way to estimate the age of a tree without cutting it down to count the rings or boring into it is by taking the d.b.h. of the tree and multiplying it by the growth factor for that species. An individual species growth factor is based on how fast a tree grows in any given year. It’s around 3 for fast growing tree species (annual growth is 25 inches or more), around 5 for moderate growing tree species (annual growth is between 13-24 inches), and around 7 for slow growing tree species (annual growth is 12 inches or less).

Since we had the values of each tree’s d.b.h. stored and the information on the individual species growth rate, that calculation is done before the trees are loaded onto the map. Besides this, for each tree the values are pulled in from the JSON file to generate a info window with the scientific name, common name, French name, links to the English and French wikis, age, d.b.h. and address for that particular tree. There is an additional check to determine the time of year we currently are in and display the tree color based on the season. This is not a fast app.


The symbols can display any of the supported 147 CSS color values so after accumulating all the data on what color the trees display I ran tests to determine the best color fit for the trees. It was like painting with words. Here are screenshots of the seasonal changes to the list of trees that have the potential to cause severe allergens:








As you can see I designated the year into 6 seasons as there is much variation between spring and fall for most species. After toggling through the different lists I discovered that there were some really old trees in Ottawa. Humbled by the almost incomprehensible ages I made sure my calculations were correct and then adjusted the filters to accommodate these giants. There where some anomalies in the data that we couldn’t help, like this one:


Which gave me a hard time and continually brought on the crashing of the browser.


And as with any data heavy app, there was a lot of crashing:


And a bit of experimenting to get the right amount of information across. Here’s an earlier version of the food bearing trees:



We’ll continue to focus on making the app faster and able to load more points as there was an additional data set released recently that added an extra 100,000 trees to the list. If you’d like to view or play with the code it’s available on Github here.

After looking through the data I couldn’t help but wonder at these elder trees and with each discovery of a new oldest came the desire to see them with my own eyes. So I gathered the oldest over 500 years of each species that had one and plotted them onto a separate Google map and made it into a bike route: Ottawa Ancient Tree Route. It’s a bit long and meandering, but there are sections that can be easily done in an afternoon. Enjoy!


4 thoughts on “The Making of OTTrees

  1. Just wanted to leave a note to express what an amazing job I think you did with this data. It works pretty quickly considering the size of your data set! And the seasonal colour palette is gorgeous. 🙂
    Love surfing around in here! I’m intending to pay a bike visit to a few of the highlights you called out.

  2. Geo guy here. Neat project! Loading all data from JS will kill many browsers. An alternative would be to put it into a PostGIS database and load the data from there. It could be setup to only retrieve the data within the extents and with the filters specified.

    More work of course but just an idea if you wanted to make it more performant.

  3. Thanks! That is a good idea. I’ll check it out and see how much it would help with loading.

Comments are closed.