GreenArc

• 

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for GreenArc

Here's a ready-to-paste "About the project" write-up in Markdown:

---

Inspiration

Cities are getting hotter. London recorded its hottest day ever in July 2022, with temperatures exceeding 40°C — and the urban core was measurably hotter than surrounding areas due to the Urban Heat Island effect. At the same time, research is unambiguous: access to tree canopy and green space directly reduces heat-related mortality, lowers rates of depression and anxiety, improves air quality, and strengthens communities. Yet decisions about where to plant trees — and whether the investment is justified — are still largely made through slow, opaque processes that exclude most of the people they affect.

We wanted to build something that changed that. Not a dashboard, not a visualisation for its own sake, but a real planning tool — one that gives a city official and a tenant association the same analytical power, and produces outputs they can both actually use.

What it does

GreenArc lets any user draw planting zones on a live heatmap of London's urban heat distribution. The tool immediately models the cooling effect of tree canopy at that location using an established urban forestry model, calculates the total planting cost and financial payback period, identifies the affected London boroughs via reverse geocoding, and generates a professional AI-authored planning briefing via the Anthropic API — formatted for direct use in a planning submission.

The cooling model applies a logarithmic diminishing-returns curve to reflect the real-world dynamic where early tree planting delivers the greatest marginal benefit. If $T_b$ is the baseline temperature at a point, $n$ is the number of trees planted in the zone, $c = 0.003$°C per tree, $S$ is the scale factor, and $C_{\max} = 6$°C is the hard cooling cap, then the adjusted temperature $T_a$ is:

$$T_a = \max\left(22,\ T_b - C_{\max} \cdot \frac{\ln(1 + nc/c)}{\ln(1 + S)}\right)$$

This ensures the model remains physically plausible at all zone sizes — a small pocket park and a large urban forest are treated very differently.

How we built it

The backend is a Node.js/Express API with three endpoints. The point cloud of London's urban heat grid is loaded into memory at startup and mutated in place on each recalculate request, avoiding database overhead for a dataset of this size. Spatial operations — point-in-polygon testing, area calculation, centroid extraction — are handled by Turf.js. Borough names are resolved via the Nominatim reverse geocoding API. The AI briefing is generated by claude-sonnet-4 with a system prompt that positions the model as a critical urban planning advisor rather than a promotional writer — it will recommend rejection of a poorly conceived plan as readily as approval of a good one.

The frontend is a Vite app with an interactive map, polygon drawing tools, and a live metrics panel that updates on every submission.

Challenges

The hardest problem was calibration. A cooling model that produces implausible outputs — a single small polygon dropping a neighbourhood by 10°C — destroys trust in the tool immediately. Getting the logarithmic curve tuned so that results feel physically grounded across zone sizes ranging from a courtyard to a large park took significant iteration.

Reverse geocoding at speed was also non-trivial. Nominatim imposes rate limits and returns inconsistent address fields depending on the area queried — some centroids return a borough, others a suburb or city_district. The fallback chain in borough.js handles this gracefully, but building it required working through a lot of edge cases across different parts of London.

Finally, prompting the AI briefing to be genuinely critical rather than generically positive required careful system prompt design. Early versions were too encouraging. The final prompt explicitly instructs the model to evaluate spatial feasibility, challenge the financial assumptions, and deliver a firm recommendation with specific reasoning — which produces output that professionals can actually trust.

What we learned

Geospatial tooling is remarkably powerful once you commit to a library. Turf.js handles almost everything — area, containment, centroids, unions — with a clean, composable API that made the spatial layer of this project far less painful than expected.

We also learned that AI output is only as useful as the trust it earns. A briefing that always says "great idea, proceed" would be ignored by any professional within seconds. The extra effort spent making the model critical, specific, and plainspoken — no markdown, no bullet points, just two direct paragraphs — is what makes the feature genuinely useful rather than decorative.

What's next

Species-specific tree modelling with per-species cooling coefficients, canopy spread, and maintenance costs. Exportable planting grids in GeoJSON, CSV, and PDF. User profiles and project persistence so planners can save, version, and collaborate on proposals across sessions. And eventually, multi-city support — because the Urban Heat Island problem is not unique to London.

Built With

• claude
• electronjs
• leaflet.js
• node.js
• turfjs