feat(waterdata): name every column the OGC collections return

[thodson-usgs]

TL;DR: Adds named, documented parameters for 20 columns that the Water Data OGC collections return and that could previously be passed only through **queryables; keyword calls send the same request as before. Until #427 merges, the service responds with HTTP 400 to get_peaks(qualifier=...), as it does to qualifier passed through **queryables. The maintainer should confirm the choices below, including a parameter order that changes positional calls.

Stacked on #422, #423 and #424; merge order is in #426. Review only the last commit.

Changes

Getter	Added
get_field_measurements	control_condition, day, field_measurements_series_id, measurement_rated, month, reading_type, time_of_day, year
get_peaks	qualifier, time_of_day, value
get_monitoring_locations	revision_created, revision_modified, revision_note
get_combined_metadata	data_gap_interval, reading_type
get_time_series_metadata	data_gap_interval, parameter_description
get_field_measurements_metadata	reading_type
get_channel	channel_location_direction

• Descriptions are adapted from each collection's /schema. day, month and year are typed int | list[int], as in get_peaks.
• The properties lists of get_monitoring_locations and get_channel add their missing columns. get_monitoring_locations joins the documented-columns monitor; get_channel stays out because its list names the output column channel_measurements_id where the schema has id.

For the maintainer

• Parameter order: the new parameters are inserted before properties, so a positional call that passes properties or a later argument now binds it to a new parameter (in get_field_measurements and get_time_series_metadata, properties was the fourth). Placing them after each getter's last named parameter would avoid this; feat(waterdata): request v1 of the Water Data API, pinnable through api_version #422's statistics_begin and fix(waterdata): accept the continuous method_category queryable #423's method_category are also inserted mid-signature.
• Not added: the ~240 monitoring-location attributes (county_name, site_type, ...) that every data collection accepts as filters but does not return. They stay in **queryables.
• get_peaks(value=...) is typed as a string, because the service transmits peak values as strings to preserve precision.
• fix(waterdata): send the qualifier filter as a JSON array #427 sends qualifier as a JSON array and, when rebased onto this PR, removes qualifier from _NEWLY_NAMED.
• Set the NEWS.md date (09/22/2026) to the merge date.

Verification

• Offline: 1214 passed, 23 deselected, coverage 98.94%. ruff, mypy, lint-imports, complexipy and xenon pass.
• Rerunning the /schema-to-signature comparison finds no unnamed returned column in the eleven collections.
• Live: filtering on a value taken from a response returned only matching rows for measurement_rated, reading_type, control_condition and parameter_description.
• Live: documented-columns monitor (tests/waterdata_properties_test.py) with monitoring-locations added, 6 passed (2026-09-29).

🤖 Generated with Claude Code

[ehinman]

I think putting the new input parameters before properties makes sense. Using positional argument orders to pull data is not very robust on the user's part, so I don't see an issue with changing the positions of the arguments, if only to encourage calling out the inputs specifically.

One question, why are all these PRs merging to main as opposed to the switch to v1? There's a lot of redundancy in these PRs. I'll admit I don't quite understand what's going on with the conflicts and what not. I'll re-read the issue #426.

[thodson-usgs]

There's a lot of redundancy in these PRs.

Yes, these build off each other. Is that what you mean?

Simplest to go in order described in issue #426, and work through them one by one. Merging before moving to the next. I'll work through the first couple, then check back in.