Add lake features from the NHD

[lawinslow]

Link to lake polygons so that catchment and lakes can be linked as first-class entities.

[dblodgett-usgs]

What would we expect in the services for this with regards to 'first-class' entities? At this point, the API is based on the idea that everything is an outfall of some identifiable watershed. A reach is tied to it's outlet, a monitoring point is an outlet, etc. The equivalent for lakes exists and, for lakes that don't have surface-water outflows, lakes have closed surface water basins.

Following this thinking, we could bring lakes into the database and wire them into the API such that you could use the navigation tools starting at an identified lake or starting at some other indexed feature and returning the lakes according to some navigation result. e.g. Give me all the water quality sites upstream of this lake or give me all the lakes in the watershed upstream of this water quality site. The nuance of 'on network' or 'off network' is one I'd like to explore, not just for lakes. With catchment indexing, we have to use additional inference to determine the network connectivity of a feature. Something to ponder.

[lawinslow]

The main way I was thinking was using a different linking technique. Correct me if I'm wrong, but for streams (and I assume rivers) you are just snapping the points to a line. What would be great would be better recognition of lakes as covering a surface area during that linking process. So instead of using the artificial line that "flows" through the lake to reference sample sites, you use points that fall within the lake polygon itself.

In this way, it's still a network. It can still be represented as a directed graph structure (which I assume you're probably using for flowlines/streams anyway). It really just modifies how linking is done.

Then, as you mention, it would be great to be able to query for 'all nutrient variables upstream of this lake". Or even, "all the lake data upstream of this lake", but really the first one would be most used and relevant.

[lawinslow]

Calling @jread-usgs here if he wants to chime in.

[jordansread]

I think 'all nutrient variables upstream of this lake' is a compelling use-case, and one that probably steers a lot of stream/river nutrient work anyhow. I've made this point before, but the reason we spend so much time calculating fluxes and loads is because of the impact to what they are fluxing into, i.e., lakes, drinking water reservoirs, the gulf, etc. The 4 biggest cities in the US get their drinking water from reservoirs or lakes. I agree w/ Luke's premise that lakes and reservoirs should be first class citizens in NLDI not just because they are often overlooked by these efforts (no offense!) but because they represent a primary (or at least a close second) driving use-case for NLDI.

[dblodgett-usgs]

@lawinslow you are making some assumptions that aren't correct. NLDI doesn't link data to reaches unless a person has already established that link (gives a reachcode and measure to the system). If a reachcode and measure is given, it just maps that to a comid catchment and carries on. Otherwise, the NLDI crawler just drops points into the catchment they reside in. There's some data model nuance in what you are talking about that we don't have in the NLDI. My point about everything being an outfall is really all there is. We don't use and won't adopt the artificial path construct that relates a 1-d network (of waterbodies) to a 2-d waterbody. It has a number of issues that can be discussed offline if you like.

That said, and to respond to @jread-usgs a bit, the NLDI doesn't have first or second class data... per say. There is catchment connectivity (just the topology and feature ID) and things linked to catchments. Catchments have multiple representations (flowlines, polygon boundary, set of associated features from source A, B, C, etc.

In this issue, we should be talking about the services. So lets assume we have access to lake polygons linked to the catchment network putting aside the issue of 'on network' or 'off network' for a minute.

Using the current API we could do something like:
http://cida.usgs.gov/nldi/lake/{identifier}/navigate/{navigationMode}/wqp to get back all the wqp sites {navigationMode} of a given lake. Similarly we could do:
http://cida.usgs.gov/nldi/wqp/{identifier}/navigate/{navigationMode}/lake to get back all the lakes {navigationMode} of a wqp site. Note that the lake and wqp identifier can be switched to any linked source. Also note that the current implementation only supports point features (and the special case of reaches which are lines) but supporting linked features of any type will be a near future.

If we need a new {navigationMode} because upstream-downstream isn't what's needed to serve lake applications, that's what we need to talk about here.

If, on the other hand, we want to treat lakes like catchments, and implement a crawler that looks at how crawled data is associated with a waterbody it knows about (lake), then we should have that conversation over here: https://github.com/ACWI-SSWD/nldi-crawler/issues We should also expand that conversation to talk about waterbodies and how we are going to link things to waterbodies generally. I'm generally uncomfortable with the semantics of lakes as wide rivers have many (all?) of the same characteristics from a data model point of view and need to be treated on the same spectrum of data.

If the {navigationMode} detail or other aspects of the services need to be adapted to lake use cases, let's let's open a new issue that gets at that in particular?

[jordansread]

OK, I guess my "first class" comment is related to the catchments or flowlines all being associated with flowing water and/or connectivity, vs the lake catchments do not exist and it isn't clear how data are linked to the lake water bodies. Is this not the case?

[lawinslow]

Yeah, to echo @jread-usgs comment.

If we need a new {navigationMode} because upstream-downstream isn't what's needed to serve lake applications, that's what we need to talk about here.

What if I wanted to do two things.

1. Get all stream observations in a lake catchment (and segregate based on upstream lake or stream observation, imagine we were looking at the Wisconsin river. Alternating river/reservoir reaches.
2. Get all lake/reservoir observations upstream of a specific stream or river reach?

Can I do this?

[dblodgett-usgs]

It's not clear to me what you mean by a lake catchment. A catchment is an area between an inflownode and an outflow node. There is a reach (1D) geometry that connects the inflownode and outflownode. In some cases, there is a lake along that geometry. In other cases, the outflow of the lake is coincident with the outflow node of the catchment (not common because confluences don't typically occur at a lake outfall). In other cases there are lake features that do not take part in the network at the scale of NHDPlus.

There are all kinds of interesting places (like waterbodies) that are not on the 1D geometry connecting inflow and outflow nodes. Are the catchments upstream of such points are not really resolved.

So, maybe this falls into the suite of functionality that would allow us to split catchments at arbitrary locations? So we could more precicely identify 'lake catchments'?

[lawinslow]

Ah, getting too wrapped up in the jargon. Lake watershed is more apt. What observations have been made of water up-watershed of the lake.

Yeah, may be a use-case of split catchments.