# Spatial Product Lifecycle Management

Enterprise geospatial operations require a disciplined transition from monolithic GIS repositories to federated, domain-aligned data products. Spatial Product Lifecycle Management establishes the operational framework for provisioning, versioning, routing, and retiring geospatial assets within a Geospatial Data Mesh & Domain-Driven Architecture. This cluster defines production-ready implementation patterns, enforces strict architectural separation, and codifies measurable SLAs for data architects, platform engineers, GIS data stewards, and enterprise tech teams. The methodology bridges foundational mesh principles with domain-driven design, ensuring that spatial products operate as autonomous, discoverable, and secure computational boundaries. For a comprehensive overview of the underlying architectural paradigm, refer to Geospatial Data Mesh Fundamentals.

Figure — The managed lifecycle of a spatial product; each transition is gated by quality checks and deprecation windows.

stateDiagram-v2
  [*] --> Experimental
  Experimental --> Production: promote after quality gates
  Production --> Deprecated: superseded by new version
  Deprecated --> Archived: deprecation window elapsed
  Archived --> [*]

# Domain Isolation & Zero-Trust Routing

A spatial product must be treated as an independent domain boundary with explicit ingress/egress controls. The architectural shift moves away from shared enterprise geodatabases and centralized ETL orchestration toward decentralized ownership with standardized interoperability contracts. Platform engineers must implement domain-specific routing at the API gateway and service mesh layers, ensuring that vector tile requests, raster processing jobs, and metadata queries are routed exclusively to the owning domain’s compute plane. Security boundaries are enforced through zero-trust network policies, attribute-based access control (ABAC), and cryptographic signing of spatial payloads. The architectural blueprint for this isolation is codified in Spatial Domain Boundary Design, which provides canonical patterns for decoupling spatial domains while maintaining interoperable data contracts.

# Production-Ready Policy Enforcement

Implementing ABAC at the gateway requires declarative policy-as-code. The following Open Policy Agent (OPA) Rego policy enforces spatial extent validation and CRS compliance before routing requests to downstream tile servers:

package spatial.gateway

import rego.v1

# Default deny
default allow = false

# Allow if request matches domain contract
allow if {
    input.method == "GET"
    input.path = ["tiles", domain, _, _, _, _]
    domain == input.headers["X-Domain-ID"]
    is_valid_crs(input.query["crs"])
    within_spatial_extent(input.query["bounds"], data.domain_extents[domain])
}

is_valid_crs(crs) if {
    crs in {"EPSG:4326", "EPSG:3857", "EPSG:32633"}
}

within_spatial_extent(bounds, extent) if {
    bbox := split(bounds, ",")
    min_x := to_number(bbox[0])
    min_y := to_number(bbox[1])
    max_x := to_number(bbox[2])
    max_y := to_number(bbox[3])
    min_x >= extent.min_x
    min_y >= extent.min_y
    max_x <= extent.max_x
    max_y <= extent.max_y
}

# Diagnostic Steps for Routing Isolation

1. Verify Policy Evaluation: Execute opa eval -i input.json -d policy.rego "data.spatial.gateway.allow" to confirm deterministic routing decisions.
2. Trace Mesh Propagation: Use istioctl analyze or equivalent service mesh CLI to validate that VirtualService and DestinationRule objects restrict cross-domain egress.
3. Audit Cryptographic Signatures: Inspect X-Payload-Signature headers against domain-specific public keys. Reject requests with expired timestamps or mismatched CRS claims.

# Deterministic Scoping & Metadata Automation

Transitioning raw geospatial datasets into managed products requires explicit Scoping Rules for Spatial Products. Data architects must define spatial extent, temporal cadence, resolution thresholds, coordinate reference systems, and consumption interfaces before provisioning infrastructure. Metadata Cataloging for Raster/Vector assets must be automated through schema-validated manifests that capture lineage, processing provenance, quality metrics, and access tiers. These manifests feed directly into the federated catalog and enable cross-domain discovery without exposing underlying storage topologies. The operational shift from project-centric GIS workflows to product-centric delivery models is governed by Product Thinking for GIS Datasets, which establishes the criteria for treating spatial assets as consumable, versioned, and SLA-bound products rather than static file drops.

# Idempotent Manifest Provisioning Workflow

Metadata registration must be idempotent to prevent catalog drift during CI/CD retries. The following pipeline pattern validates, hashes, and registers spatial manifests:

#!/usr/bin/env bash
set -euo pipefail

MANIFEST_DIR="./spatial-manifests"
SCHEMA_URL="https://raw.githubusercontent.com/ogcincubator/spatial-data-mesh/main/schema/v1.2/spatial-product-manifest.schema.json"

for manifest in "${MANIFEST_DIR}"/*.json; do
  # 1. Schema validation (idempotent)
  ajv validate -s "${SCHEMA_URL}" -d "${manifest}" --strict=false

  # 2. Compute deterministic content hash
  HASH=$(sha256sum "${manifest}" | awk '{print $1}')

  # 3. Register only if hash differs from catalog state
  if ! catalog-api check-hash --id "$(jq -r '.productId' "${manifest}")" --hash "${HASH}"; then
    catalog-api register --file "${manifest}" --signature "${HASH}"
    echo "Registered: $(jq -r '.productId' "${manifest}")"
  else
    echo "Skipped (idempotent): $(jq -r '.productId' "${manifest}")"
  fi
done

# Diagnostic Steps for Catalog Sync Failures

1. Schema Drift Detection: Run ajv compile -s schema.json to verify backward compatibility. Reject manifests that introduce breaking changes to spatialExtent or temporalCadence without major version bumps.
2. Hash Collision Resolution: If catalog-api check-hash returns inconsistent states, force a re-index using catalog-api reconcile --force-sync and verify against the authoritative GitOps repository.
3. Lineage Breakage: Trace processingProvenance.pipelineId fields. Missing upstream job identifiers indicate broken ETL handoffs; trigger automated pipeline reconciliation.

# Versioning, Promotion & Immutable Artifacts

Spatial product lifecycle management relies on deterministic workflows that guarantee idempotent state transitions across staging, validation, and production environments. Versioning must adhere to semantic conventions extended for geospatial contexts (e.g., v1.2.0-crs:EPSG:4326-res:10m). Promotion pipelines must enforce cryptographic checksums, spatial topology validation, and automated regression testing against baseline extents. Immutable artifact registries prevent unauthorized overwrites, while signed releases ensure supply chain integrity.

# GitOps Promotion & Rollback Pattern

Leverage Kubernetes-native GitOps controllers to manage spatial tileset promotions. The following declarative workflow ensures atomic version swaps:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: spatial-product-urban-landcover
spec:
  project: geospatial-mesh
  source:
    repoURL: https://git.enterprise.internal/spatial-products/urban-landcover.git
    targetRevision: v2.1.0-epsg:3857-res:0.5m
    path: deploy/overlays/prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ApplyOutOfSyncOnly=true
  destination:
    server: https://k8s.prod.mesh.internal
    namespace: spatial-prod

# Diagnostic Steps for Promotion Failures

1. Topology Validation: Run ogrinfo -so -al tileset.gpkg and verify Geometry Type and CRS alignment. Reject promotions with mixed geometry types or unprojected coordinates in projected domains.
2. Rollback Verification: Execute argocd app rollback spatial-product-urban-landcover --to-revision v2.0.0-epsg:3857-res:1m and confirm p95 query latency returns to baseline within 90 seconds.
3. Artifact Integrity: Verify Cosign signatures using cosign verify --key domain-public.pem tileset-tarball.tar.gz. Unsigned artifacts must trigger immediate pipeline termination.

# Governance Workflows & SLA Enforcement

Cross-team governance requires automated policy enforcement, measurable SLAs, and continuous drift detection. Platform engineers must instrument spatial products with standardized telemetry: tile cache hit ratios, raster processing queue depths, and metadata synchronization latency. SLAs should be codified as Prometheus alerting rules and enforced via admission controllers. For authoritative spatial interoperability standards, consult the OGC API - Features specification, and for policy-as-code implementation patterns, reference the Open Policy Agent Documentation.

# Measurable SLA Baselines

# Diagnostic Runbook for SLA Breaches

1. Identify Bottleneck: Correlate spatial_tile_latency_seconds with opa_evaluation_duration_seconds. High latency in both indicates gateway policy misconfiguration.
2. Validate Data Contracts: Run spatial-contract-validator --manifest ./product.json --endpoint https://api.mesh.internal/tiles. Mismatches indicate upstream schema drift.
3. Enforce Remediation: Apply automated scaling policies via Horizontal Pod Autoscaler (HPA) with custom metrics. If breaches persist beyond 15 minutes, trigger circuit breaker routing to fallback static tilesets and notify domain stewards.