Skip to content

docs(ogc): describe actively_monitored_wells as all-groups - #874

Open
jirhiker wants to merge 1 commit into
BDMS-974-a-4-fix-brittle-sql-filter-in-actively-monitored-wellsfrom
chore/actively-monitored-wells-description
Open

docs(ogc): describe actively_monitored_wells as all-groups#874
jirhiker wants to merge 1 commit into
BDMS-974-a-4-fix-brittle-sql-filter-in-actively-monitored-wellsfrom
chore/actively-monitored-wells-description

Conversation

@jirhiker

@jirhiker jirhiker commented Aug 22, 2026

Copy link
Copy Markdown
Member

Stacked on #866. Base is BDMS-974-a-4-fix-brittle-sql-filter-in-actively-monitored-wells — one commit, three files, and it only makes sense alongside the view change in that PR.

Why

#866 drops the lower(trim(g.name)) = 'water level network' predicate, so ogc_actively_monitored_wells now covers currently-monitored wells in any group. The layer's published prose still described the old filter:

A well appears here only if it belongs to the Water Level Network group and its most recent monitoring-status entry reads "Currently monitored"…

That becomes wrong the moment 986e0eb85ab3 runs, and it is served to every consumer on /ogcapi/collections.

What changed

  • Collection description (public and internal config) now keys the layer on the monitoring status alone, whichever group the well belongs to.
  • Duplicate ids are documented. The view joins through group_thing_association without aggregating, so a well in several groups appears once per group. The id field entry now says it is not unique within this collection — the kind of thing a client otherwise discovers when its keyed-by-id map silently drops rows.
  • group_name loses its claim that it is always the Water Level Network.
  • Keywords drop water-level-network for monitoring-status.

Heads-up for #866, unrelated to this PR

There is an uncommitted migration in the shared worktree, d4e5f6a7b8c9_cm_legacy_mirror_tables, whose down_revision is c3d4e5f6a7b8 — the same parent as #866's 986e0eb85ab3. Whoever owns that work will need to re-parent it onto 986e0eb85ab3, or alembic ends up with two heads.

Verification

uv run pytest tests/test_ogc.py tests/test_ogc_field_descriptions.py tests/test_ogc_field_metadata.py tests/test_pygeoapi_mount.py → 68 passed, 1 skipped, on this branch with #866's migration applied.

🤖 Generated with Claude Code

@github-actions

github-actions Bot commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

Coverage

79.19% total — gate is 75%.

BDMS-974 drops the "group name = 'water level network'" predicate from
ogc_actively_monitored_wells, so the layer now covers currently-monitored
wells in any group. The published prose still described the old filter and
would have shipped wrong the moment that migration ran.

The collection description now keys the layer on the monitoring status
alone, and says what the join actually produces: a well in several groups
appears once per group. That last point matters enough to repeat at field
level -- the id column is no longer unique within the collection, which
is the kind of thing a client discovers by having its keyed-by-id map
silently drop rows. group_name loses its claim that it is always the
Water Level Network.

Keywords drop water-level-network for monitoring-status.

Co-Authored-By: Claude Opus 5 <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