Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discovering events located on NHD nodes #40

Open
pauldzy opened this issue Dec 5, 2016 · 0 comments
Open

Discovering events located on NHD nodes #40

pauldzy opened this issue Dec 5, 2016 · 0 comments

Comments

@pauldzy
Copy link

pauldzy commented Dec 5, 2016

I thought I'd write this up on as I was tracking down a related bug in my alternative navigation code. I think this is important to NLDI as NLDI navigation only occurs by entire flowlines meaning that we are starting and ending at nodes for every run.

The way NHD is structured the nodes that connect flowlines are represented by two or more reach measures in the network. So for two connected flowlines, reach A running 100 to 0 and reach B running 100 to 0, reach A measure 0 is the same spatial location as reach B measure 100. Point events may for various reasons (often simply random choice) end up at either reach measure.

In this example, we have two flowing reaches with an event located at the bottom of the upstream reach at measure 0.
capture3

If we navigate for whatever reason up only the lower of two, the issue is that we do not discover the event which is indexed to the bottom of the upstream reach. Yet most observers would consider this event to also be upon the downstream reach spatially. This is a vagary of the NHD.

Now a couple of solutions have been proposed over the years.

The first and what we actually do is to simply consider these reach measures to be conceptually different regardless of occupying the same space. So in the scenario above you are not going to find that event unless your navigation moves up onto the upstream reach. In the legacy navigators based on cost and measures, navigation rarely ends precisely on the node between flowlines. So this issue in fact does not show very often. However, my point is with the NLDI navigator it is going to be much more evident.

A second solution would be to add support into the event finding module to consider these reach endpoints to be spatially the same. So after ending an upstream run at reach B measure 0, the event finding logic would need to check the measure 100 of the reach (or reaches) above for an event. This sounds possible until we account for node connects are not in fact spatially equal. So in the example below the upper red reach does flow into the lower red reach and measure 0 and measure 100 of the two are not in the same location though the VAA tables implies they are.
capture1

So if we only navigate the lower reach, would we want to return that event at measure 0 of that upper reach? We might if we consider the connection nodes between these reaches to be "teleporters" of water but I think most observers would think there is some kind of implied connection that covers the gap and thus the nodes are not the same spatially.

A third solution would be to consider these node locations as "zones of uncertainty" to simply be avoided. In other words don't stick point events at measure 0 or measure 100, consider 0.0001 or 99.9999 instead. This would hike the point events up onto a single flowline. This might better match the NLDI model of whole flowline navigation.

I wanted to do some testing of the NLDI navigator to make sure something has not already been built into the system beyond how the legacy navigators do things. This circles back to our discussion of whether NPDES data was ever loaded into NLDI, If we could get that loaded, I could include some actual NLDI results.

Cheers,
Paul

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants