Prophet

The insight

Every piece of land has a history. Before a greenfield estate becomes 400 residential lots, it was a single rural holding. Before that rural holding was rezoned, the corridor around it changed first — infrastructure extended, adjacent parcels consolidated, planning overlays shifted.

These transitions aren’t random. They follow patterns that repeat across decades and geographies. A parcel’s neighbours, its zoning trajectory, the timing of surrounding subdivisions, the sequence of ownership changes — these are features in a prediction problem that nobody is modelling at scale.

The data exists. Australian state governments maintain cadastral registries with historical snapshots going back years. Every lot plan, every boundary change, every status transition is recorded. But it sits in static GIS layers that nobody treats as training data.

The grid is the training set: identical cell IDs across years give a clean time-series per cell however the parcel boundaries moved.

Architecture

Prophet is a three-layer system: a Dagster-orchestrated pipeline that converts raw cadastral vectors into a cellular grid, a FastAPI tile server that serves that grid as pre-computed MVTs, and a React/MapLibre GL frontend that renders temporal comparisons in the browser.

DAGSTER PIPELINE          FASTAPI SERVER          REACT FRONTEND
────────────────          ──────────────          ──────────────

source_metadata           GET /perspectives       MapLibre GL
      │                     /{id}/mvt/{tick}      VectorTileSource
source_vector_data          /0/{z}/{x}/{y}.mvt          │
      │                           │                setUrl() on
base_cadastre_blob_grid ──→ pickle.load(mvt)       tick change
      │                           │                     │
blob_matrix_mvt_tiles       application/vnd.        Zustand store
(MultiPartition:            mapbox-vector-tile      manages state
 time × tile)

Partitions:                 Serves ~300 pre-       Temporal
T2020, T2021 ×              computed tiles         scrubbing via
z12-z14 Brisbane tiles      per time period        timeline UI

The blob matrix

The core data structure is a spatial grid we call the blob matrix. Instead of comparing vector boundaries across time (computationally expensive and geometrically unstable when parcels split, merge, or shift), Prophet rasterises each cadastral snapshot onto a fixed cellular grid aligned to coordinate-space origins.

The grid generation algorithm aligns cells to (0,0) in the projected CRS, guaranteeing that grids produced from different spatial extents but the same cell size are perfectly aligned for temporal stacking:

Each cell is a Shapely box(x, y, x + cell_size, y + cell_size) with a deterministic ID derived from its grid coordinates: cell_{col}_{row}. A 10-metre grid over the Brisbane cadastral extent produces tens of thousands of cells per time period.

The cellularisation step then tags each grid cell with the attributes of every parcel it intersects via gpd.sjoin(). A single cell that overlaps multiple parcels appears multiple times in the output — one row per grid-cell/parcel intersection. The geometry stays as the original grid cell (not the intersection polygon), making the output directly suitable for vector tile encoding.

This representation enables three things that raw cadastral vectors don’t:

Temporal alignment

Identical grid IDs across years produce a clean time-series per cell, regardless of how the underlying parcel boundaries changed. A cell that was tagged with one rural lot plan in 2020 and three residential lot plans in 2025 carries that transition as a structured attribute delta.

ML-ready features

Each cell’s attribute history across time periods is a feature vector. The grid is the training dataset.

Tile-native storage

The grid cells map directly to MVT features with zero additional geometry processing.

Dagster pipeline

The data pipeline uses Dagster’s asset-based orchestration with multi-dimensional partitioning. Every transformation is an auditable, reproducible asset. The critical design decision is the MultiPartitionsDefinition that combines time and tile dimensions:

The tile key generation uses mercantile to enumerate all tiles in the Brisbane bounding box across zoom levels 12-14, producing ~150 tile keys per zoom level. Combined with 2 time partitions, the pipeline manages ~300+ discrete MVT assets, each independently materializable.

The blob grid asset takes raw parcel vectors, creates the aligned grid via create_grid(), then performs the spatial join via cellularize_parcels(). The MVT asset then clips the grid to each tile’s Web Mercator bounds, reprojects to EPSG:4326, encodes features with mapbox_vector_tile.encode() at 4096 extent with 256-unit buffer, and persists the bytes via Dagster’s filesystem IO manager.

New years of cadastral data process incrementally. The pipeline ingests annual snapshots as they’re published and extends the training window without reprocessing history.

Tile serving

FastAPI serves pre-computed MVTs at sub-5ms response times. The endpoint follows standard slippy map conventions:

GET /perspectives/{perspective_id}/mvt/{tick}/0/{z}/{x}/{y}.mvt
  → Content-Type: application/vnd.mapbox-vector-tile

Each tile is stored as a pickled bytes object by Dagster’s filesystem IO manager, keyed by the multi-partition path {tile_partition}/{time_partition}. The server deserialises and returns raw bytes — no runtime geometry processing, no database queries, no spatial computation at serve time.

All spatial computation happens once during pipeline materialisation. The tile server is a glorified file server with content-type headers.

Frontend

The React frontend uses MapLibre GL JS for rendering and Zustand for state management. The critical interaction is temporal scrubbing — switching between time periods to observe cadastral change.

When the user selects a different time period, the frontend calls VectorTileSource.setUrl() on the existing MapLibre source, swapping the tile URL template to point at the new time partition. MapLibre handles cache invalidation and tile re-fetching automatically. The map doesn’t reinitialise; only the tile data changes.

The Zustand store manages source selection, tick selection, map viewport state, and a viewport size constraint system that calculates approximate viewport dimensions in metres (via Haversine) to enforce modeller size limits from server-side configuration.

An inverse-bbox overlay (a polygon covering the entire world except the source extent) provides visual context for the dataset boundary. The overlay uses a GeoJSON polygon with an outer ring at [-180.1, -90.1] to [180.1, 90.1] and an inner ring cut from the source’s bounding box. The application ships as an Electron desktop app for cross-platform delivery.

Why this matters

The prediction gap

Property markets are valued on comparable sales and discounted cash flows. Both methods are backward-looking. They tell you what land was worth; they don’t tell you what it will become.

The highest-value information in property development is knowing which land will transition — from rural to residential, from low-density to high-density, from fragmented ownership to consolidated parcels. Developers who identify these transitions early acquire at agricultural prices and sell at residential prices. The margin between those two numbers is where billions of dollars are made.

Identifying transition candidates currently requires local knowledge, planning contacts and years spent driving corridors. That does not scale and cannot be backtested — which is the specific gap a grid with a per-cell history closes, because a held-out time period gives you a test set.

What the model learns

Subdivision precursors

A rural parcel surrounded by recently subdivided lots, within 2km of an infrastructure corridor extension, with a planning overlay change in the last 3 years, has a quantifiable probability of subdividing within the next 5 years.

Rezoning trajectories

Parcels don’t rezone in isolation. They follow spatial sequences. A rezoning event in one area predicts subsequent rezonings in adjacent areas with measurable lead times.

Tenure transition signals

Consolidation of adjacent parcels by a single entity, changes in lot status, and shifts in ownership tenure duration are precursors to development activity.

Value inflection points

The moment a parcel’s probability of transition crosses a threshold, its residual value (current use) diverges from its potential value (highest and best use). Prophet identifies these inflection points.

The stack

Market

Property developers making land acquisition decisions. Infrastructure funds evaluating corridor investments. Local government forecasting housing supply and infrastructure load. Institutional investors seeking quantified, backtestable exposure to land transitions. Valuation firms needing data-driven highest-and-best-use assessments.

Relationship to Starling

Prophet is the physical-world intelligence complement to Starling, our financial signal intelligence platform. The thesis is the same: public data, properly modelled over time, contains latent predictive signal that markets haven’t priced.

Roadmap

Phase 1 (current): temporal visualisation engine

POC complete. Blob matrix pipeline ingests QLD cadastral snapshots from ArcGIS FeatureServer, generates time-partitioned cellular grids across zoom levels 12-14, and serves interactive MVT tiles via FastAPI. The data foundation is proven.

Phase 2: multi-source enrichment

Overlay zoning layers, planning scheme amendments, ownership transfer records, and transaction data onto the temporal grid. Each additional signal dimension increases model expressiveness.

Phase 3: pattern training

Train temporal models on the enriched grid. Identify subdivision precursors, rezoning sequences, and tenure transition signatures. Backtest against held-out time periods.

Phase 4: prediction API

Expose parcel-level predictions via API. Subscription model by coverage region and prediction horizon.

Phase 5: national scale

Extend to all Australian states. Each new jurisdiction adds training data and validates model generalisability.