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, and #427, a qualifier fix found while testing them. 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.
5. fix(waterdata): send the qualifier filter as a JSON array #427: send the qualifier filter as a JSON array.

Order	PR	Branch	Head (2026-09-29)	Commits on the branch
1	#422	feat/waterdata-api-v1	58ff493a	#422
2	#423	fix/continuous-method-category	6a146f78	#423, based directly on main
3	#424	test/documented-properties-monitor	73451c49	#422 (58ff493a), #423 rebased onto #422 (6121a965), #424 (73451c49)
4	#425	feat/expose-returned-columns	908e7412	the three above, then #425 (908e7412)
5	#427	fix/qualifier-json-array	9b25bceb	#427, based directly on main

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 (6121a965) 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 after test(waterdata): assert documented columns match the collection schema #424. It is stacked on test(waterdata): assert documented columns match the collection schema #424.
• fix(waterdata): send the qualifier filter as a JSON array #427 last. It does not depend on v1, but it conflicts with fix(waterdata): accept the continuous method_category queryable #423 in the get_continuous docstring and needs edits to feat(waterdata): name every column the OGC collections return #425's lines. Merging it last means only this branch is rebased. It could merge first, but then feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422 through feat(waterdata): name every column the OGC collections return #425 would all need rebasing.

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 6121a965
git rebase --onto upstream/main 58ff493a
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 6121a965
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 73451c49
git push --force-with-lease origin feat/expose-returned-columns

# After #425 merges: rebase #427 and make the four edits listed in its
# description (rehearsed 2026-09-29: 1218 passed, live checks pass on v1).
git switch -C fix/qualifier-json-array origin/fix/qualifier-json-array
git rebase upstream/main
git push --force-with-lease origin fix/qualifier-json-array

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.

[thodson-usgs]

@ehinman, I staged a series of PRs related to the v1 API along with some bugs that surfaced in the process. I've ran some automated reviews and tests already, so your review can focus on high level organization and clarity of doc.