As WRES TD, I would like to discuss the location metadata gaps that we anticipate a WRDS Location API potentially filling

[epag]

---

Author Name: Hank (Hank) Original Redmine Issue: 82731, https://vlab.noaa.gov/redmine/issues/82731 Original Date: 2020-09-10

---

The subject says it all. In order to understand if and how to integrate the WRDS Location API to fill in gaps related to location metadata, we need to understand what those gaps are and where the fit in within the WRES.

If you have some ideas about gaps it could fill, please comment. Thanks!

Hank

---

Redmine related issue(s): 85964

---

[epag]

---

Original Redmine Comment Author Name: Chris (Chris) Original Date: 2020-09-10T16:04:36Z

---

One of the major benefits of the current, template-based netcdf output is that output comes packed with location coordinates. Without that data, having an id without a lot of context for what it stands for makes correlating it with a location on the earth a massive pain. Location provides context, and context is king. If we could get latitude and longitude (bonus points for geometry) with the results, we'd be able to do a lot more with the results. I understand that it will not always be available, but if we could supply the lat and lon of locations from the service (and maybe lat and lon from PIXML files that supply them), our outputs would offer a lot more value. I can only create basic graphs with our current csv output, but I can plot results with our current netcdf output. It would take a significant amount of work and the creation of really complicated systems with more points of failure in order to perform that sort of location metadata correlation after the fact.

[epag]

---

Original Redmine Comment Author Name: Hank (Hank) Original Date: 2020-11-18T14:51:07Z

---

This is just a discussion ticket, so it doesn't really need to be associated with a release, but I think it helps to keep it on the front burner by doing so.

Hank

[epag]

---

Original Redmine Comment Author Name: Jesse (Jesse) Original Date: 2020-12-07T22:10:26Z

---

USGS data provides complete geographic context in-band to results from NWIS IV service. No other data source that I'm aware of does this (unless specified explicitly in CSV, which reminds me I need to put that in the wiki if I didn't already).

The NWM data service from WRDS does not provide geography (see https://nwcal-wrds.[host]/api/prod/nwm/ops/short_range/streamflow/nwm_feature_id/12202300/?reference_time=2020-12-07T00%3A00%3A00Z for example). The WRDS AHPS data service probably comes close enough with lat/lon/crs (CRS is "NAD83" on the one example I tried, which we could translate to whatever EPSG that is).

If the National Water Model provided geographic context in-band, we could probably read it. Since it does not, WRES can't guess as to what it is. Maybe we need the capability of reading whatever out-of-band NWM blob provides geographic context alongside the NWM data, perhaps as part of the NWM reader. This would be kind of complex and brittle, though, and basically modifying what the original source had for location.

[epag]

---

Original Redmine Comment Author Name: Chris (Chris) Original Date: 2020-12-08T13:45:42Z

---

I thought the idea was that the location service would get wrangled into this thing at some point.

[epag]

---

Original Redmine Comment Author Name: James (James) Original Date: 2020-12-08T13:47:55Z

---

Chris wrote:

I thought the idea was that the location service would get wrangled into this thing at some point.

I think so. But it would be better to get the geo context inband to the ingested sources first. The sources are canonical in that sense. The service would just supplement missing info., never override it (in my opinion).

[epag]

---

Original Redmine Comment Author Name: Chris (Chris) Original Date: 2020-12-08T15:00:22Z

---

I'd still trust the source data if it said a location for Maine was on the Moon over whatever WRDS gives me.

I think a glaring flaw that needs to be addressed is that WRDS needs to be packing geospatial metadata with their responses. They need to be returning basic info like lat and lon, like NWIS does, regardless of what we want or plan to do with it.

[epag]

---

Original Redmine Comment Author Name: James (James) Original Date: 2020-12-08T15:07:17Z

---

Ha, yes.

Agree on your second point too, providing it comes from the original sources. If they're just adding it in themselves, I am more skeptical, at least without an explicit request (for the same reason you note). I would prefer them to represent the sources as closely as possible and for us to be able to decide about how to augment them.

[epag]

---

Original Redmine Comment Author Name: Chris (Chris) Original Date: 2020-12-08T15:17:56Z

---

Maybe all of this will go away in v2.1; I keep seeing hints that lat and lon will be in the output. Until then, our options will be to trust WRDS or have a mechanism for loading and reading the correct routelink (gross). If we ask WRDS for location data within the source, it will be up to them to load the routelink and presumably add in the correct midpoints, which they will most likely do by hitting the location service. If we aren't satisfied with that, we can hit the location service and... get the exact same metadata. This is all for the NWM data, mind you. I imagine it might be the same with their ahps data, though.

Gotta say, though; not a huge fan of being beholden to their services.

[epag]

---

Original Redmine Comment Author Name: James (James) Original Date: 2020-12-14T16:32:33Z

---

Some discussion happened, probably not all.

[epag]

---

Original Redmine Comment Author Name: Jesse (Jesse) Original Date: 2020-12-15T17:03:27Z

---

It's a discussion.