Skip to content

docs(ogc): record the null measuring-point height default - #897

Merged
ksmuczynski merged 1 commit into
stagingfrom
kas-mp-height-null-handling-bdms-980
Aug 28, 2026
Merged

docs(ogc): record the null measuring-point height default#897
ksmuczynski merged 1 commit into
stagingfrom
kas-mp-height-null-handling-bdms-980

Conversation

@ksmuczynski

@ksmuczynski ksmuczynski commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

Summary

Documents how three published OGC layers handle wells with no recorded measuring-point height. Cris Morton and Ethan Mamer confirmed the existing behavior is correct on 2026-08-26, so this is one new doc, no code change.

Why

This PR addresses the following problem / context:
The behavior was already in the SQL but had never been confirmed as intentional. An unwritten answer invites the next reader to "fix" it, which would quietly change what three published layers return.

Changes

Implementation summary - the following was changed / added / removed:

  • Decision record. New docs/measuring-point-height-null-handling.md covering the decision, who made it, and its effect on the affected layers.
  • Follow-up condition, not a code change. The doc states what would justify revisiting the default and asks future analytic layers to follow the same convention.

Notes

Any special considerations, workarounds, or follow-up work to note?

  • None

water_well_summary, depth_to_water_trend_wells and
water_elevation_wells layers all substitute zero for a missing
measuring-point height, treating the measuring point as ground
surface. That has been in the SQL since those views were written
(COALESCE(measuring_point_height, 0)), but nothing said whether zero
was the intended default or an accident. BDMS-974 surfaced the
question and deferred it here rather than change the views on a guess.

Cris Morton and Ethan Mamer confirmed on 2026-08-26 that zero (ground
surface) is the right default, so the views are correct as written and
there is no code change to make. What was missing was the record: the
next person to read that substitution would ask the same question, and
without an answer on file the safe-looking move is to exclude those
rows, which would silently drop wells from three published layers.

The doc keeps the consequence visible rather than acting on it. Wells
with no recorded measuring point are less certain than the rest and
nothing in the output says so. Adding a flag column would touch three
view definitions and the field descriptions for a subset nobody has
sized yet, so the decision records the condition for revisiting it
instead.

Refs BDMS-980
@github-actions

Copy link
Copy Markdown
Contributor

Coverage

79.30% total — gate is 75%.

@ksmuczynski
ksmuczynski merged commit 672c1ed into staging Aug 28, 2026
10 checks passed
@ksmuczynski
ksmuczynski deleted the kas-mp-height-null-handling-bdms-980 branch August 28, 2026 19:27
@ksmuczynski ksmuczynski self-assigned this Aug 28, 2026
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