Quick Reference

Menu map

21 models in total. The Spatial Data group also carries a direct 🗺️ Map View link to /spatialfeature/map.

Key status vocabularies (enums)

• GeometryType: Point · MultiPoint · LineString · MultiLineString · Polygon · MultiPolygon (GeoJSON, CamelCase)
• FeatureStatus: proposed · active · inactive · closed · superseded
• LayerSourceType: internal · imported · api · external_gis · simulated
• ShareAccessLevel: none · metadata · geometry · read · export
• ResponsibilityType: owner · custodian · operator · maintainer · approver · regulator · viewer · affected_party
• SpatialRelationType: intersects · within · contains · touches · crosses · overlaps · near
• RelationshipStatus: detected · active · changed · ceased · acknowledged · resolved · ignored
• EvaluationStatus: queued · running · completed · partial · failed
• RuleSeverity: info · advisory · warning · critical
• EventStatus: pending · emitted · acknowledged · failed · closed
• DeliveryStatus: queued · sending · delivered · acknowledged · retrying · failed
• PermissionScope: tenant · layer · feature
• GeometryDisclosurePolicy: none · centroid · simplified · full
• TransferDirection: inbound · outbound
• ReconciliationStatus: open · matched · exception · resolved
• TenantStatus: active · suspended · archived

The tenants & layers

The spatial flow, in the demo codes

Feature RP-2026-001 (Northern Connector Upgrade) → run EVAL-2026-0101 → relationships intersects ML-1032 / EA-076 / TX-220-07 + near PIPE-44 (197 m) → rules ROAD_INTERSECTS_* / ROAD_NEAR_PIPELINE → events EVT-2026-000101…105 → delivery to orchestrator → disclosure coordination_basic → outbound GeoJSON data transfer → audit disclosure.sent → reconciliation RECON-2026-0011 (matched). Ceased lifecycle: RP-2026-002 → EVT-2026-000090 (relationship_ceased) → RECON-2026-0012 (exception STALE_RELATIONSHIP).

The demo data set

The deterministic v0.2 cross-tenant coordination scenario: a proposed road upgrade interacting with a mining lease, an environmental constraint area, a gas pipeline and a transmission line, each surfaced as an Orchestrator-routed coordination event under a disclosure profile. 98 rows across all 21 models.

CRS handling

• Storage / exchange CRS: EPSG:4326 (all seeded geometry, GeoJSON in and out).
• Analysis CRS: EPSG:7856 — distance / buffer / overlap-area / simplification are transformed into a metric projection first (v0.2 config/spatial_engine.yaml). Phase 2 runtime.

Translation & modelling notes

• Source pack ships a module / enum {} / model {} DSL dialect (space-separated field lines, uuid relation Target FKs, datetime system auto-fields) across 9 dsl/*.dsl files. It was translated to native DSL (apps/gist/schema/gist.dsl): uuid primary → Int pk, relation → ref (+ auto display_template), enums inlined verbatim, system/deleted* fields and index/unique constraint lines dropped, metadata → metadata_json (SQLAlchemy reserved). This is the same dialect as the spatial app (v0.1 of this pack).
• Denormalisation is intentional & pervasive (per the DSLCore denorm philosophy): child rows carry tenant_id, layer/feature/rule codes etc. alongside the FK.
• 3 models carry two FKs to the same parent (LayerShare source/target Tenant; SpatialRelationship and SpatialEvent source/target SpatialFeature) — tab_config.yaml gives each role a distinct drill-down label.
• Seed field gotchas: overlap_area_m2 (a _m2 suffix a plain [a-z_] grep truncates) and SpatialEvent.emitted_at (not occurred_at). Valid terminal enums used: SpatialEvent.status = emitted, ReconciliationCheck.status = matched/exception.
• The spatial engine, rules/triggers/events, disclosure enforcement, Orchestrator delivery and reconciliation are Phase 2 (page 03) — Phase 1 models the outcomes statically.