Merge order for the Water Data v1 PRs (#422–#425)

[thodson-usgs]

This issue tracks the four open PRs from 2026-09-22 that move the Water Data OGC getters to v1 and act on what that migration found. They must merge in the order below: #424 and #425 are stacked on the PRs before them, and #422 and #423 conflict in NEWS.md.

Merge order

1. feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422: request v1 of the Water Data API, pinnable through api_version. Closes v1 of the water data apis has been released #421.
2. fix(waterdata): accept the continuous method_category queryable #423: accept the continuous method_category queryable.
3. test(waterdata): assert documented columns match the collection schema #424: live test that each getter's documented columns match the collection's /schema.
4. feat(waterdata): name every column the OGC collections return #425: named parameters for 20 returned columns.

Order	PR	Branch	Head (2026-09-29)	Commits on the branch
1	#422	feat/waterdata-api-v1	a4bbcf25	#422
2	#423	fix/continuous-method-category	1460ecd0	#423, based directly on main
3	#424	test/documented-properties-monitor	e181c46d	#422 (a4bbcf25), #423 rebased onto #422 (08136c88), #424 (e181c46d)
4	#425	feat/expose-returned-columns	2aa8648b	the three above, then #425 (2aa8648b)

All four branch from main at 75e56ab6, are drafts, and pass every CI check on their current heads.

Why this order

• feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422 before fix(waterdata): accept the continuous method_category queryable #423. The two conflict only in NEWS.md, where both add a top entry, so either could merge first on its own. But test(waterdata): assert documented columns match the collection schema #424 and feat(waterdata): name every column the OGC collections return #425 already include a copy of fix(waterdata): accept the continuous method_category queryable #423 rebased onto feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422 (08136c88) with that conflict resolved. Merging feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422 first reuses that resolution. Merging fix(waterdata): accept the continuous method_category queryable #423 first means resolving the conflict again in the other direction and rebuilding test(waterdata): assert documented columns match the collection schema #424 and feat(waterdata): name every column the OGC collections return #425. This order does not delay the fix for the failing nightly live run (35698389879): feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422 moves the queryables snapshot to v1, the v1 snapshot already lists method_category, and the monitor passes after feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422 alone.
• test(waterdata): assert documented columns match the collection schema #424 after feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422 and fix(waterdata): accept the continuous method_category queryable #423. Its live test compares the documented columns with /schema. It fails unless data_gap_interval (documented in feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422) and method_category (documented in fix(waterdata): accept the continuous method_category queryable #423) are both present.
• feat(waterdata): name every column the OGC collections return #425 last. It is stacked on test(waterdata): assert documented columns match the collection schema #424.

After each merge

main is squash-merged, so a merged PR's commit never becomes an ancestor of main. The later branches keep showing its changes until they are rebased. After each merge, rebase the next branch onto main, cutting at the stack commit that corresponds to the PR that just merged:

git fetch upstream && git fetch origin

# After #422 merges: replace #423 with its copy from the stack,
# which already has the NEWS.md conflict resolved.
git switch -C fix/continuous-method-category 08136c88
git rebase --onto upstream/main a4bbcf25
git push --force-with-lease origin fix/continuous-method-category

# After #423 merges:
git switch -C test/documented-properties-monitor origin/test/documented-properties-monitor
git rebase --onto upstream/main 08136c88
git push --force-with-lease origin test/documented-properties-monitor

# After #424 merges:
git switch -C feat/expose-returned-columns origin/feat/expose-returned-columns
git rebase --onto upstream/main e181c46d
git push --force-with-lease origin feat/expose-returned-columns

Checked locally (2026-09-29): after a squash merge of #422 onto 75e56ab6, #423's stack copy rebases cleanly; after a squash merge of that, #424 and #425 rebase with no conflicts.

The SHAs above are commits in the current #424 and #425 branches. They stay valid if a PR is only rebased before it merges. If a PR's content changes first (for example, after review), rebuild the branches above it before continuing.

Before each merge

• Mark the PR ready for review. main requires one approving review.
• Set the PR's NEWS.md date to the day it merges (feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422, fix(waterdata): accept the continuous method_category queryable #423 and feat(waterdata): name every column the OGC collections return #425 all say 09/22/2026). The next rebase will then hit a one-line NEWS.md conflict; keep both entries, newest on top.
• Wait for CI to pass on the rebased head. type-check runs over the PR merged into main.

Open items on individual PRs

• feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422 lists four decisions for the maintainer to confirm: the v0 horizon of 2027-06-01, the configuration file accepting api_version, routing the dropped queryables to v0 rather than translating them forward, and the NEWS date.
• fix(waterdata): accept the continuous method_category queryable #423's endpoint monitor compares each family's default version with the version waterdata/endpoints.py requests. On its main-based branch the ogcapi case fails live, because main requests v0; it passes once feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422 merges.