Approach

Most spatial problems aren't really about maps — they're about systems, scale, and trade-offs that happen to be spatial.

My path ran from field-based environmental science into computation, and it left me treating a block, a coastline, or a whole sea as a system to be read before it's a dataset to be processed.

A few principles run through everything I build.

01

Open by default

Everything runs on open-source tools and open data.

I work Python-first — GeoPandas, Shapely, Rasterio, OSMnx, rustworkx — and lean on open solvers like HiGHS rather than proprietary licences. That's not ideology for its own sake: it means the work is reproducible, inspectable, and yours to keep. No vendor lock-in, no black boxes you can't audit, and analysis that still runs the same way in five years.

In practice North Sea MSP
02

One way of thinking, every scale

The same spatial reasoning holds whether the unit is a building or a sea.

My work runs from urban blocks of a few dozen buildings up to the entire North Sea across seven countries. The resolution and tools change; the reasoning doesn't. Moving comfortably between architecture-scale detail and regional structure means I can connect a single design decision to its wider footprint — and keep a city-scale model grounded in what's actually happening on a street.

In practice REEF & North Sea MSP
03

Make the intractable run

Scale is a computation problem before it's an analysis problem.

A lot of useful questions die because the honest version is too big to compute — millions of GPS points a day, tens of thousands of origin–destination pairs, an optimisation across hundreds of sites. I put real effort into making those tractable: vectorised and JIT-compiled pipelines, routing tuned to run in seconds, problems reframed so the expensive computation happens once.

And once the expensive part is done, I build the pipeline so the next question — different weights, a different region, a different year — can be re-asked, not re-derived from scratch. The payoff is asking the bigger question instead of the convenient one.

In practice IBX transit routing
04

Build toward a decision

An analysis should help someone choose, not just describe.

I tend to frame problems as scenarios and trade-offs — what shifts if you prioritise cost over ecology, capacity over equity — and where it helps, I turn the result into something people can steer: an interactive map or a tool with sliders, not a static report. Precomputing the heavy part lets a non-technical stakeholder explore the options in real time and see the consequences for themselves.

In practice North Sea MSP
05

Read the system, not just the data

Where the effects land is often more interesting than where you'd expect.

My background is in physical geography — how the configuration of a system shapes what happens to it. I bring that habit to spatial work, looking for the second-order and non-linear effects: the impact that shows up far from the obvious place. A new transit line changes travel times in neighbourhoods nowhere near it, and that's usually where the real finding is.

Reading the system also means checking the model against it — validating against reference data where I can, documenting assumptions, treating metadata and reproducibility as part of the deliverable rather than an afterthought.

In practice Urban tree crowns
See it applied
Selected work →