Overview

What this is

GIS Tenancy Portal (gist) is the gis_tenancy_dslcore v0.2 specification baseline rendered as a working app: a multi-tenant geospatial coordination platform. Each organisation's tenant holds its own GIS layers and spatial features, shares them selectively with other tenants, and relies on a spatial engine to detect how features interact across tenant boundaries — surfacing those interactions as events, disclosing them to the right party under controlled profiles, and reconciling the shared picture.

It is deliberately not a full GIS replacement. It exists to exercise tenancy and need-to-know access, cross-tenant sharing, spatial relationships, events/triggers, disclosure-controlled payloads, Orchestrator delivery and governance/reconciliation.

The domain, in one paragraph

An organisation owns one or more tenants (each with domains); users hold roles with permissions scoped to tenant/layer/feature. A tenant's GIS layers contain spatial features (geometry + properties), and layer shares grant another tenant a level of access (metadata / geometry / read / export). Feature responsibility records who owns or regulates each feature. A spatial evaluation run compares features and records spatial relationships (intersects, touches, near…); a spatial rule defines which relationships matter and at what severity. A matching relationship, via a trigger definition, raises a spatial event, which is delivered (event delivery) to the Orchestrator and — where a disclosure profile allows — disclosed through a data transfer. Every material action is an audit event, and cross-tenant state is verified by reconciliation checks.

The 21 models by area

🏢 Organisation & tenancy

Organisation · Tenant · TenantDomain — the ownership and tenant-isolation backbone.

🔑 Access & sharing

User · Role · UserRole · Permission · LayerShare — who can do what, and which layers cross tenant boundaries.

🗺️ Spatial data

GISLayer · SpatialFeature · FeatureResponsibility — the layers, the geometry, and who's responsible for each feature.

📐 Spatial evaluation

SpatialEvaluationRun · SpatialRelationship · SpatialRule — the engine runs, the detected relationships, and the rules that judge them.

⚡ Events & triggers

TriggerDefinition · SpatialEvent · EventDelivery — what to watch, the events raised, and their delivery to consumers (the Orchestrator).

🔒 Disclosure & integration

DisclosureProfile · DataTransfer · AuditEvent — what may be disclosed, the transfers that carry it, and the audit trail.

🔁 Reconciliation

ReconciliationCheck — verifying that shared/disclosed state stays consistent across tenants.

The demo scenario

The Queensland Demo Transport Agency (transport tenant) proposes the Northern Connector Upgrade — road project RP-2026-001 on its road_projects layer. A spatial evaluation run (EVAL-2026-0101) compares it against four other tenants' features and records four relationships:

Boundary case RP-2026-003 touches the lease (advisory). Each match raises a spatial event (EVT-2026-000101…105), delivered to the DSLCore Orchestrator (http://orchestrator:8000/api/v1/events, idempotent) and disclosed under the coordination_basic profile — which shares geometry and coordination properties but denies confidential business fields (internal_target_model, commercial_notes, resource_estimate). The whole batch is an outbound data transfer, audited, and reconciled (RECON-2026-0011, matched).

The v0.2 relationship lifecycle is seeded too: RP-2026-002 (Eastern Bypass) once intersected the lease but the relationship ceased after realignment (EVT-2026-000090, gis.spatial.relationship_ceased) — and its reconciliation is an open exception (STALE_RELATIONSHIP) awaiting resync with the Orchestrator.

98 rows across all 21 models. Geometry is stored/exchanged in EPSG:4326; metric operations (distance, overlap area) are computed in EPSG:7856 (documented; Phase 2 runtime).