Skip to content

Conversation

@ldecicco-USGS
Copy link
Collaborator

No description provided.

@ehinman
Copy link
Collaborator

ehinman commented Dec 2, 2025

Hey there, I have time to review Wed/Thur.

#' @export
#' @param monitoring_location_id `r get_params("continuous")$monitoring_location_id`
#' @param parameter_code `r get_params("continuous")$parameter_code`
#' @param statistic_id `r get_params("continuous")$statistic_id`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to self to test: is this really a valid input? Isn't the stat id for continuous 00011?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a valid input, but only 00011 will return data. We could take it out of the argument list so hopefully it's less confusing? I'll double check there aren't some weird random other stat ids for continuous data.

Co-authored-by: Elise Hinman <121896266+ehinman@users.noreply.github.com>
Co-authored-by: Elise Hinman <121896266+ehinman@users.noreply.github.com>
#'
#' @description `r get_description("continuous")`
#'
#' Currently, the services only allow up to 3 years of data to be requested with
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a hard and fast rule?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edit: asked Mike, got the answer. This is a helpful piece of info!

@ehinman
Copy link
Collaborator

ehinman commented Dec 4, 2025

This test produced a warning and the properties argument didn't work:

test = read_waterdata_continuous(
  monitoring_location_id = "USGS-01646500",
  time = "2024-01-01/2025-01-01",
  properties = c("time", "parameter_code", "time_series_id", "value", "unit_of_measure")
)

Requesting:
[https://api.waterdata.usgs.gov/ogcapi/v0/collections/continuous/items?f=json&lang=en-US&skipGeometry=TRUE&limit=50000&properties=time%2Cparameter_code%2Ctime_series_id%2Cvalue%2Cunit_of_measure&monitoring_location_id=USGS-01646500&time=2024-01-01%2F2025-01-01](vscode-file://vscode-app/Applications/Positron.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html#)
                                   
Warning message:
Unknown or uninitialised column: `monitoring_location_id`. 
Error in `order()`:
! argument 2 is not a vector
Show Traceback

It returns the requested data, just with all the columns.

@ldecicco-USGS
Copy link
Collaborator Author

Good catch, hard to order on a column that doesn't exist.

Co-authored-by: Elise Hinman <121896266+ehinman@users.noreply.github.com>
knitr::kable(head(uv_trim))
```

Next we'll clean up the discrete water quality "qw" data to make it easy to follow in this tutorial.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to keep using "qw" when its original source doesn't exist anymore? I kinda pre-date "qw" so find it kind of a weird abbreviation.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's wrong with the quality of water measured at our gage?? 😂(I'll change it!)

Once the pipeline has completed, you can load the `ohio_discharge` data frame into your environment with `tar_load`:

```{r eval=FALSE}
tar_load(ohio_discharge)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SNAZZY. I just tested this out and it worked great.

* USGS APIs (Water Data)
* Water Quality Portal (WQP)
* USGS APIs (Water Data), which are new or in-development .
* National Water Information System (NWIS) - Legacy system that will eventually be retired.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double-checking with Mike...but I believe I remember him saying that while Water Services is going away, the collective "NWIS" will still be a term used in this ecosystem. @mikemahoney218-usgs do I have that right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The challenge specifically for dataRetrieval is that we called all of those functions (whether it was waterservices or waterdata) NWIS (readNWISxxx). I'll do a little effort to make it clear that NWIS Water Services are going to be retired - but for most dataRetrieval users, that distinction will not matter. We want to be clear that all the NWIS dataRetrieval functions will stop working eventually.

Co-authored-by: Elise Hinman <121896266+ehinman@users.noreply.github.com>
Copy link
Collaborator

@ehinman ehinman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, @ldecicco-USGS. Thanks for the opportunity to review. Approved.

@ldecicco-USGS ldecicco-USGS merged commit d8d252f into DOI-USGS:develop Dec 4, 2025
1 check passed
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.

2 participants