Use GET with comma-separated values for multi-value waterdata queries#233
Merged
thodson-usgs merged 1 commit intoMay 15, 2026
Merged
Conversation
thodson-usgs
force-pushed
the
fix-waterdata-get-multivalue
branch
from
cdf2295 to
7fe353b
Compare
7 tasks
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the Water Data OGC request builder to use comma-separated GET parameters for multi-value queries where supported, reducing reliance on POST+CQL2 while preserving POST behavior for monitoring-locations.
Changes:
- Adds
_CQL2_REQUIRED_SERVICESto keepmonitoring-locationson POST+CQL2. - Formats date/time parameters before choosing GET vs POST.
- Adds unit tests for multi-value GET, monitoring-location POST fallback, scalar handling, numeric list joining, and date interval formatting.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
dataretrieval/waterdata/utils.py |
Updates request construction logic to comma-join list parameters for GET except for CQL2-required services. |
tests/waterdata_test.py |
Adds tests covering the updated request construction behavior. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The OGC Water Data API supports comma-separated multi-value parameters for most collections, so list-valued kwargs (e.g. parameter_code= ["00060", "00010"]) can now be sent as a single GET request instead of a POST+CQL2 body. The monitoring-locations collection still rejects comma-separated values and so retains the POST+CQL2 path; a new _CQL2_REQUIRED_SERVICES frozenset is the single removal point for when the upstream API closes that gap. Date/time parameters are now formatted to ISO8601 once at the top of _construct_api_requests ahead of the routing decision, so both paths see a post-formatted string instead of the original list shape. Tests cover the GET multi-value path, the POST+CQL2 path (including the full CQL2 envelope shape), single-value scalars, numeric lists, and the two-element date-list interval case. Closes DOI-USGS#210
thodson-usgs
force-pushed
the
fix-waterdata-get-multivalue
branch
from
a432be8 to
40ed9eb
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Route most multi-value
waterdatakwargs through GET with comma-joined values instead of POST+CQL2. The OGC API supports?parameter_code=00060,00010for all collections exceptmonitoring-locations, which still rejects comma-separated values and so retains the POST+CQL2 path.Service-scoped routing
A new
_CQL2_REQUIRED_SERVICES = frozenset({"monitoring-locations"})constant picks the path. When the Water Data APIs team enables comma-separated support onmonitoring-locations, emptying this set drops the POST branch in one edit.Date formatting moved before routing
_format_api_datesnow runs once at the top of_construct_api_requests, so both routing paths consume an already-formatted ISO8601 string rather than the original list shape.Closes #210