Skip to content

docs: add ADR3 for serving water data via OGC API - EDR#777

Open
jirhiker wants to merge 5 commits into
stagingfrom
adr-ogc-edr
Open

docs: add ADR3 for serving water data via OGC API - EDR#777
jirhiker wants to merge 5 commits into
stagingfrom
adr-ogc-edr

Conversation

@jirhiker

Copy link
Copy Markdown
Member

What

Adds ADR3.md — an architecture decision record proposing OGC API - EDR (Environmental Data Retrieval) as the public delivery interface for the Bureau's observational datasets.

Docs-only change. No code, config, or schema touched.

Why

  • Directly serves the ADR1 unification/interoperability goal — a published OGC standard instead of bespoke per-dataset REST endpoints.
  • The data is already point + time + parameter, which is exactly EDR's shape (near 1:1 map onto the existing models).
  • Fills a real gap: the GeoServer IaC work covers WMS/WFS/OGC API - Features, but GeoServer does not implement EDR. This clarifies the division of labor.

Decision summary

  • Facade approach: pygeoapi as a read-only EDR service over the existing PostgreSQL/PostGIS DB. FastAPI stays the system of record + write/QC path; GeoServer keeps Features/WMS.
  • Collections: waterlevels and water-chemistry.
    • waterlevelsGroundwaterLevelObservation via WellTimeseries
    • water-chemistryWaterChemistryAnalysis via WaterChemistryAnalysisSet (one parameter per analyte)
  • Transducer observations: manual and transducer readings live in the same table, split by WellTimeseries.equipment_idEquipment. Each transducer deployment is exposed as an EDR instance (temporal extent, recording_interval, instrument metadata).
  • Merge decision: a collection-level water-level query at a well returns the merged manual + transducer series on one time axis; instances are the drill-down to isolate one deployment.

Reviewer notes

  • This ADR decides direction and boundaries, not a file-by-file implementation plan (provider-vs-view bridging and deployment wiring are follow-up).
  • Open items flagged in the ADR: schema bridging (custom pygeoapi providers vs. SQL read views), chemistry analyte cardinality, transducer volume/decimation, private-IP Cloud SQL access, and QC/visibility publication gating.
  • Numbering: root currently has ADR1; ADR2 (API concurrency) lives in worktrees, not committed here. Named this ADR3 — rename if you'd rather it be ADR2.

🤖 Generated with Claude Code

Propose adopting OGC API - EDR as the read-only delivery interface for
groundwater-level measurements (manual + transducer time series) and
water-chemistry analyses, served by pygeoapi as a facade over the existing
PostgreSQL/PostGIS database.

Decision: two collections (waterlevels, water-chemistry); transducer
deployments (Equipment) exposed as EDR instances; collection-level water-level
queries return the merged manual + transducer series. FastAPI stays the system
of record; GeoServer keeps Features/WMS.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@jirhiker jirhiker changed the title docs: ADR3 — serve water-level & water-chemistry data via OGC API - EDR docs: add ADR3 for serving water data via OGC API - EDR Jul 12, 2026
Remove the Cloud SQL private-IP (10.10.0.3) risk bullet and its matching
acceptance-criterion line.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
jirhiker and others added 3 commits July 12, 2026 08:59
Rewrite ADR3 against the real staging models (Thing/Location, Observation,
TransducerObservation/TransducerObservationBlock/Deployment/Sensor,
Sample/Parameter) instead of the divergent geoserver-iac branch schema.

Key corrections:
- EDR is added to the pygeoapi service already mounted at /ogcapi (core/pygeoapi.py),
  not a new standalone service.
- Publication gating uses release_status = 'public' via ogc_* views, matching
  the existing OGC API - Features pattern.
- Parameter names come from Parameter.parameter_name; units from default_unit.
- Note that pygeoapi's bundled EDR providers are gridded, so an observational
  PostgreSQL-backed EDR provider is likely required.

Add the executable spec:
- tests/features/edr-water-data.feature (@edr @wip, 9 scenarios)
- tests/features/steps/edr_water_data.py (reuses the in-process TestClient;
  Background skips while the EDR collections are unimplemented)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Implements ADR3: two EDR collections (waterlevels, water_chemistry) served by a
custom PostgreSQL EDR provider on the existing pygeoapi /ogcapi mount.

- alembic z9a0b1c2d3e4: ogc_waterlevels (manual Observation UNION transducer
  TransducerObservation via Deployment) and ogc_water_chemistry views, both
  publication-filtered to release_status = 'public'.
- core/edr_provider.WaterEDRProvider: BaseEDRProvider serving CoverageJSON
  (PointSeries) from the flat ogc_* views; implements locations/area/position/
  cube and exposes transducer Deployments as EDR instances.
- core/pygeoapi.py: register the EDR collections alongside the feature
  collections in the generated pygeoapi config.
- tests/features/environment.py: seed manual + transducer water levels, pH
  chemistry, and non-public (draft) records for the EDR scenarios.
- tests/features/edr-water-data.feature + steps: 8 scenarios (catalog, metadata,
  depth-to-water CoverageJSON, merged manual+transducer, instances, chemistry
  area-by-analyte, publication gating, conformance). @wip removed.

Verified end-to-end against a PostGIS container via TestClient (all EDR checks
pass). Note: pygeoapi 0.23.4 routes generic EDR query patterns ahead of their
instance-scoped counterparts (greedy collection_id path), so instance discovery
is served but instance-scoped data queries are not; documented in ADR3.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant