GIS Tenancy Portal
A multi-tenant spatial coordination portal (gis_tenancy v0.2) — organisations and tenants
each own their GIS layers and spatial features, share them selectively across tenant boundaries,
and let a spatial engine detect relationships (intersects, touches, proximity) between features
that raise coordination events, disclosures and reconciliations.
Its central question:
Across tenants that each hold their own geospatial data — transport, council, mining, utility, regulator — which features spatially interact, which of those interactions a rule cares about, and how is that surfaced, disclosed to the right party and reconciled, without any tenant seeing more of another's data than they're entitled to?
The headline flow is spatial evaluation → relationship → rule → event → disclosure → Orchestrator, all scoped by tenancy and controlled by layer sharing and disclosure profiles.
🗺️ Interactive map view
Beyond the CRUD screens, an interactive Leaflet map renders the spatial features live at:
/spatialfeature/map
It plots every SpatialFeature geometry (coloured by layer, click for details) on an
OpenStreetMap base map — so the demo's Northern Connector Upgrade road footprint crossing a
mining lease, an environmental area and a transmission line is visible, not just a set of
coordinates. Features come from this app (/spatialfeature/map/features.json, a GeoJSON
FeatureCollection); only the base tiles are external. The tile provider is a one-line config at
the top of apps/gist/templates/map/map.html (OpenStreetMap by default; swap for a
self-hosted/keyed provider, or run features-only with no basemap).
The spatial spine
Tenant → GIS Layer → Spatial Feature → (Evaluation Run) → Spatial Relationship → Spatial Rule → Spatial Event → Event Delivery / Disclosure → Data Transfer → Audit → Reconciliation
The documents
| Page | What's in it |
|---|---|
| 00 — Overview | What the app is, the domain, the 21 models by area, the demo scenario |
| 01 — Quick Reference | Menu map, every model, key status vocabularies, the demo data set |
| 02 — System Diagram | The 21-model ER diagram + architecture flow + interactive viewer |
| 03 — Phase 2 Scope | The runtime not yet built: the spatial engine, rules/triggers/events, disclosure & reconciliation |
| 04 — Architecture | Technology profile, logical components, deployment, the GIS↔Orchestrator boundary rule |
| 05 — Tenancy & Access | Access chain, roles, LayerShare sharing modes, disclosure profiles |
| 06 — Spatial Processing | Evaluation sequence, predicates, CRS (4326↔7856), the relationship lifecycle |
| 07 — Events & Triggers | Trigger definitions, event lifecycle, delivery, idempotency, failure behaviour |
| 08 — Orchestrator Interface | The boundary, outbound payloads, data minimisation, reconciliation |
| 09 — API Contracts | The SpatialPortalAPI shape (evaluate → run, relationships, health) |
| 10 — Simulation Scenarios | The 8 seeded scenarios (positive/negative/boundary/cessation) + governance cases |
| 11 — Implementation Roadmap | R0–R6 release plan; what Phase 1 already delivers |
| 12 — Test Plan | Lint, geometry, permission/disclosure, event, Orchestrator, reconciliation tests |
| 13 — Future Extensions | Spatial DB / GIS integrations / temporal evidence + package conventions |
Pages 04–13 and the Mermaid diagram sources under
asset/diagrams/were ported from thegis_tenancyfull documentation pack and adapted to gist's 21-model superset.
Status
Phase 1 (built): all 21 models render as an AI-Safe CRUD register with a dashboard, seeded with the deterministic v0.2 cross-tenant coordination scenario — a proposed road upgrade that interacts with four other tenants' features (98 rows across all 21 models).
Phase 2 (scoped, not built): the CRS-aware spatial engine (geometry/relationship evaluation in EPSG:7856), the rule/trigger/event pipeline, disclosure enforcement, data-transfer delivery, Orchestrator integration and reconciliation — see page 03.
Prototype system; draft. All organisations, tenants, users, geometries and events in the demo data are fictional.