You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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
The text was updated successfully, but these errors were encountered:
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.
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.
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
The text was updated successfully, but these errors were encountered: