3-30-300 Tree Mapping
3-30-300 Tree Analyzer
As soon as I stumbled across the 3-30-300 rule this week, I knew it would make a perfect spatial analysis project. OpenStreetMap already crowdsources tree points and park boundaries worldwide, making it the ideal open data stack to map exactly which neighborhoods meet the rule and which ones are missing trees and easy access to green spaces.
By combining OpenStreetMap data with on-the-fly spatial analysis, my 3-30-300 Tree Analyzer map allows users to analyze their own neighborhoods to evaluate every building's proximity to parks and trees.
What the Map Shows
When you run an analysis on the map, it evaluates individual buildings and color-codes them based on how well they meet the 3-30-300 benchmarks:
● Passed Both (Green): The gold standard. Buildings that have at least 3 trees nearby and sit within 300 meters of a park.
● Park Only (Yellow): Buildings that enjoy close proximity to a public park but lack immediate street-level trees.
● Trees Only (Blue): Shaded properties that have plenty of trees within a stone's throw but lack access to a larger public park.
● Failed Both (Red): Urban "gray spots" that miss out on two components of the rule, highlighting areas that planners should target for green equity.
A Quick Caveat: Because OpenStreetMap doesn't know the exact viewpoint extent of building windows, the map uses a proxy for the "3 trees" rule. Instead of viewpoints, it evaluates the presence of individual registered street trees within a 35-meter radius of the building's center.
Under the Hood: Overpass API and Turf.js
The map doesn’t rely on a heavy, pre-computed backend database. Instead, all of the heavy lifting happens right in your browser using two open-source tools: the Overpass API and Turf.js.
When you click "Analyze View," the application calculates the coordinates of your map window, expands that window outward by 300 meters to ensure it doesn't miss off-screen parks, and fires a request to the Overpass API. Overpass instantly queries OpenStreetMap's massive crowdsourced database to pull down raw geometry for every registered tree (`natural=tree`) and public park (`leisure=park`, `landuse=village_green`) in that buffered bounding box.
Once the raw data arrives, Turf.js - a client-side geospatial engine - takes over. Turf calculates the exact geographic centroid of every building currently visible on your screen. It then runs high-speed proximity algorithms, calculating the exact distance from each building's center to the nearest point on a park's outer edge, while simultaneously checking how many point-vector trees sit within a 35-meter radius.
The result is a highly responsive, spatial analysis tool built entirely with client-side JavaScript.
Making the 3-30-300 Tree Analyzer More Robust
I only spent a couple of hours creating the 3-30-300 Tree Analyzer. Because of that, it does have some severe limitations. The 30% tree canopy cover metric is missing entirely from the live code analysis. In addition, because the map relies entirely on OpenStreetMap data, it may be missing local environmental assets - meaning the results are only as accurate as your neighborhood’s local OSM map contributors.
If you have access to official tree canopy or environmental cover data for your city, you could easily adapt this code to make a much more robust version of the 3-30-300 Tree Analyzer. If you want to build upon this framework or customize it for your own town, feel free to clone the source code over on the project's GitHub repository.
Comments