Add Dynamic, Epoch-Aware Spatial Reference Support

[RichardFairhurst]

Summary
Esri’s current Spatial Reference model is static: it understands projection, datum, and units, but not time (epoch) or control network realization. That was sufficient when most work was local and datums were treated as fixed. It is no longer sufficient for a world that depends on Global Navigation Satellite System (GNSS) measurements, dynamic datums, and cross-boundary critical infrastructure.

This idea proposes a Dynamic Spatial Reference Extension that adds epoch and control-network awareness directly into the feature class Spatial Reference object, so that Esri tools can enforce it the same way they already enforce projection and datum.

This is not just a “California problem” or a “surveying problem.” It is a critical infrastructure, population mobility, and cross-jurisdictional data integrity problem.

Problem
Today, Esri’s Spatial Reference:
- Enforces: projection, datum, units, XY tolerance/resolution.
- Does NOT enforce: epoch, control network, velocity model, bearing basis, distance basis.

As a result:
- GNSS-derived coordinates are inherently epoch-dependent, but GIS treats them as timeless.
- Control networks move (especially in plate boundary regions like California), but feature classes don’t record which epoch or realization they align to.
- Bearings and distances derived from coordinates can change over time, but there is no way to track or enforce this.
- Datasets from different epochs and control networks can be merged, appended, or overlaid with no warning, silently corrupting geometry.
- Cross-boundary infrastructure (pipelines, power lines, fiber, transportation, water systems) and cross-state property ownership rely on consistent coordinates that may span multiple epochs and control realizations.

This is manageable for a single county with custom scripts and local rules. It is not manageable at national or global scale. And it cannot be solved reliably by external JSON, sidecar metadata, or custom extensions, because Esri tools only enforce what is embedded in the feature class Spatial Reference.

Why this matters (beyond “just” surveying)
1. Critical infrastructure
- Pipelines, power transmission, rail, fiber, and water systems cross state and county lines.
- If different segments are referenced to different epochs or control networks, the geometry is wrong even if the projection matches.
- This affects maintenance, safety, emergency response, and regulatory compliance.

2. Population mobility and cross-boundary property
- People buy property across state lines and move between regions.
- Parcels, easements, and rights-of-way can span jurisdictions with different control and epochs.
- Without epoch-aware SR, parcel and boundary data can drift or misalign when combined.

3. GNSS and dynamic datums
- GNSS coordinates are inherently time-dependent.
- National geodetic agencies (such as NGS in the United States) rely on Continuously Operating Reference Stations (CORS) to define modern control networks. These CORS networks are tied to specific epochs and realizations.
- The United States National Spatial Reference System (NSRS) is being modernized into a dynamic, time-dependent framework.
- The International Terrestrial Reference Frame (ITRF) — the global standard for Earth-centered coordinates — is inherently epoch-based and updated regularly.
- GIS is the last major system still treating coordinates as if the Earth is static.

4. Global interoperability
- Dynamic datums are already in use or planned in multiple regions (e.g., Australia, Europe, US NSRS modernization).
- Without epoch-aware SR, Esri becomes a bottleneck for accurate cross-border and international data exchange.

5. The true promise of the Parcel Fabric—seamless editing, authoritative record management, cross‑boundary consistency, and survey‑grade lineage—cannot be fully realized without an enhanced, epoch‑aware Spatial Reference. Parcels are not just drawings; they are legal objects tied to control networks, GNSS‑derived measurements, and bearings that change over time as the Earth moves. When the Spatial Reference lacks epoch and control‑network metadata, the Fabric can maintain topology but cannot guarantee positional integrity, especially when data crosses county or state lines or is updated from modern GNSS observations. A dynamic, time‑aware Spatial Reference is what allows the Parcel Fabric to function as a truly authoritative, future‑proof cadastral system rather than a sophisticated drawing tool.

Proposed Solution: Dynamic Spatial Reference Extension
Extend the feature class Spatial Reference object to include a “survey-grade half” that captures the dynamic and realization-specific aspects of the coordinate system.

Suggested additional fields (conceptual, not prescriptive):
- ControlNetworkID
- Identifies the control network or realization (e.g., NSRS2011, future NSRS, ITRF-based realization, regional CORS network).
- Epoch
- The reference epoch of the coordinates (e.g., 2010.00, 2022.00).
- VelocityModel
- The velocity or deformation model used (if any).
- BearingBasis
- Grid vs true, and any relevant projection-based bearing definition.
- BearingNotation
- Quadrant vs azimuth, degrees vs grads, etc.
- DistanceBasis
- Ground vs grid, and any scale factor or combination factor assumptions.
- TransformationLineage
- A record of the CRS and epoch transformations applied (e.g., Esri WKIDs and epoch shifts used).

Key behaviors and enforcement
Once this Dynamic SR Extension is embedded in the feature class Spatial Reference, Esri tools should:

1. Detect mismatches
- Prevent or warn when merging/appending/overlaying datasets with different epochs or control networks.
- Similar to how Esri currently prevents mixing different projections or units.

2. Require epoch alignment
- Just as “Project” is required to reconcile different projections, an epoch-alignment step should be required when combining data from different epochs or control networks.
- This could be implemented via new tools or extensions to existing tools (e.g., “Project with Epoch Alignment”).

3. Preserve and propagate metadata
- Ensure that the Dynamic SR metadata is preserved through geoprocessing operations, exports, and schema changes.
- Make it visible in layer properties and accessible via APIs.

4. Integrate with GNSS workflows
- Allow GNSS-derived data to be stored with explicit epoch and control network metadata.
- Support transformations from GNSS/ITRF epochs into local realizations and epochs using the Dynamic SR model.

Relationship to Bearing WKID / Bearing Profiles
A separate but related idea is the introduction of a Bearing WKID or bearing profile concept, which defines how bearings are expressed (basis, notation, distance basis, etc.).

The Dynamic SR Extension complements this by:
- Anchoring coordinates in time (epoch) and control network.
- Ensuring that bearings are recomputed correctly when coordinates are epoch-shifted or transformed.
- Providing a consistent framework for survey-grade bearings in GIS.

Why this must be native to Esri (and not just an extension)
Organizations like counties or agencies can and do build local extensions:
- Custom scripts for epoch shifting.
- Local control network alignment workflows.
- Ad hoc metadata conventions.

These work in-house, but:
- They are fragile across software updates.
- They are invisible to core Esri tools.
- They cannot be reliably enforced outside the organization.
- They cannot scale to national or global infrastructure.

Only Esri can:
- Extend the Spatial Reference object.
- Integrate Dynamic SR into the projection engine.
- Update core tools (Project, Append, Merge, Spatial Join, etc.) to respect and enforce epoch and control metadata.
- Provide a consistent, global implementation that supports critical infrastructure and cross-boundary data.

What this Idea asks Esri to do
1. Acknowledge the need for dynamic, epoch-aware spatial references as a first-class platform concern.
2. Extend the feature class Spatial Reference model to include:
- Epoch
- ControlNetworkID
- VelocityModel
- Bearing/Distance basis metadata
- Transformation lineage
3. Update core tools to:
- Detect and warn on mismatched epochs/control networks.
- Require or assist with epoch alignment before blending datasets.
4. Document and expose this model clearly so users understand:
- Why epochs matter.
- How control networks (including CORS networks) affect coordinates.
- How to maintain spatial integrity across time and jurisdictional boundaries.

Closing
This is not just a technical refinement. It is a necessary evolution for a world that depends on:
- GNSS,
- dynamic datums,
- cross-boundary infrastructure,
- and a mobile population.

Static spatial references were enough for a static view of the Earth.
They are not enough for the planet we actually live on.

Dynamic, epoch-aware Spatial References—embedded in the feature class and enforced by Esri tools—are the next logical step.