Add streamlined, hydroviz webapp specific endpoint to conus_hydrology#703
Add streamlined, hydroviz webapp specific endpoint to conus_hydrology#703
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a Hydroviz-webapp-specific CONUS hydrology endpoint that aggregates/reshapes existing CONUS hydrology API outputs server-side so the webapp can render hydrograph, monthly flow, stats tables, and summary with less client-side processing.
Changes:
- Introduces
/conus_hydrology/hydroviz/<stream_id>/<model>endpoint to return a streamlined response withhydrograph,monthly_flow,stats, andsummary. - Validates
<model>against an allowlist and computes projected min/mean/max across all models for DOY, plus per-month distributions across models.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Joshdpaul
left a comment
There was a problem hiding this comment.
This looks great, Craig! Nice and tidy return, just the info that is needed for the application.
I added a suggestion for note to remind us that the "historical" data in the return is not for the requested model, but always for the Maurer baseline. This is obvious when reading the code, but I thought a little flag here might be nice for future reference.
I noticed that a bogus stream ID will return 500 in this new endpoint, but returns 400 "bad request" in other endpoints (see http://127.0.0.1:5000/conus_hydrology/observed_climatology/100000 vs http://127.0.0.1:5000/conus_hydrology/hydroviz/100000/BNU-ESM ). I don't know if that's a big deal since this is an "internal" endpoint designed for the app, so I'll leave it up to you to change this if a 400 would be more appropriate.
Co-authored-by: Josh Paul <99696041+Joshdpaul@users.noreply.github.com>
Xref: ua-snap/hydroviz#86
Xref: ua-snap/hydroviz#98
Xref: ua-snap/hydroviz#110
This PR adds a custom hydroviz-webapp-specific endpoint to the CONUS hydrology family of endpoints. This is intentionally undocumented since it is specific to the hydroviz webapp, similar to the Arctic-EDS endpoint we use for the Arctic-EDS webapp. This PR replaces the misfire that was PR #702, which allowed us to filter by model but ultimately provided no benefit when I remembered that the hydrograph and monthly flow charts are populated using data across all models.
This PR also moves most of the data manipulation code out of the webapp and into the Data API, so things like finding the min/mean/max for each DOY across all models, or grouping data by month, don't need to be performed in the user's web browser. And all of the raw data needed to perform those calculations are also not sent to the web browser, reducing the Data API response size from 10mb down to about ~20kb, per selected stream segment.
Note that the model parameter is provided as a component of the URL path like this:
I did it this way and not via a
?models=parameter because the model parameter is not quite being used like a filter here, and thehydrograph,monthly_flow,summaryproperties of the response object provide data across all models regardless of what model is provided. Themodelvariable only affects thestatsproperty.To test, try the endpoint URL using a variety of streams and models and make sure the output is sane. That's about it!