Trace Downstream doesn't return ending barrier

TimWhiteaker · ‎11-22-2020

I have a trace network with edges (NHDFlowline) and junctions (WRProxyMZ) that has been validated. When I trace downstream from a point along an edge (green circle in figures below), using all WRProxyMZ points as barriers, with Include Barrier Features checked, the barrier that stops the trace is not returned in the results. It seems like it should be returned if Include Barrier Features is checked.

See the two screenshots below. The first shows the map layers and starting flag which I set interactively. The second shows the Trace tool inputs (no advanced options set) and the resulting map selection after running the trace.

Example data and Pro project are attached.

Starting flag (green) and junctions used as barriers (orange)Trace results -- note no downstream junction selected

JonDeRose · ‎12-07-2020

Thank you again for the clear use case and data. With your use case we were able to identify another issue and have implemented a fix related to placement of starting points in 2.7. Another issue has been created to include barrier features in the trace result when using a network junction feature class as you were doing in your initial note.

As you noted with case "a", interactive placement of trace locations using the Trace Locations pane will allow you to place starting points or barriers on an edge or junction feature. This is the default method for placing trace locations

For case "b" below, I am curious if the edge element selected is upstream or downstream of the junction feature that is not selected. If you were to interactively place a starting point at the endpoint of a line from a small scale this could inadvertently place barriers on both adjacent endpoints which could explain why the junction feature is not included in the result set. I d id notice in my testing that if I am zoomed out a bit, a barrier was placed on both the upstream and downstream edge surrounding the junction. Alternatively, you could be placing the barrier on the endpoint of the edge upstream of the junction feature alone.

Testing on my end using 2.6.3 shows that if the barrier is placed on the endpoint of the edge downstream from the junction, the junction is included in the result.

Juncitoin feature included in trace resultBarrier interactively placed on endpoint of edge downstream of the junction feature

Regarding your question about the need for SOURCEID / FEATUREGLOBALID fields when placing trace locations. We have an open issue to address some issues that are encountered when using network features (such as WRProxyMZ) as barriers in a trace. While these are honored as barrier features, there may be inconsistencies including these in the trace result as you have noticed. The alternative solution for this is case "a" as you noted above. Another approach would be use to another user defined class for the trace locations.

When placing starting points and barriers in a trace network, the SOURCEID / FEATUREGLOBALID are not required; however, these are honored if present.

Using to determine trace locations allows you to filter which features are used as trace locations. Perhaps you have a feature class that contains features you want to use as barriers; however, you only want a certain type of feature, or specific features to serve as barriers... In this case you could populate only the features you want to serve as barriers with SOURCEID/FEATUREGLOBALID information. When the trace is executed, only these features would be used as either the starting point or barrier from the class.

To clarify, case, if your class has 20 records, but only 2 have SOURCEID/FEATUREGLOBALID populated with a valid value, only those 2 would be used as starting points or barriers in the trace.

If these fields are not present, the geometry of the feature class will be used to intersect the network feature geometry and place either the starting point or barrier.

user-defined feature class used as a barrier feature

This is outlined here:

Thanks,

Jon

View solution in original post

JonDeRose · ‎12-02-2020

Good morning Tim,

I wanted you to know that I was taking a look at the use case you outlined above. I agree that the behavior appears strange. Could you let me know which version of ArcGIS Pro 2.6 you are working with? Is this 2.6.0 or do you also have a patch applied? (2.6.3 for example).

I'll reach back out once I've had an opportunity to dig in a bit more.

TimWhiteaker · ‎12-02-2020

I've got 2.6.0 currently. My Pro instance can't connect to the update server, so I'm unable to upgrade to 2.6.3.

TimWhiteaker · ‎12-06-2020

I manually installed the 2.6.3 patch and got the same result: the junction stopping the trace isn't selected. However, I discovered a couple of other curious behaviors:

a. If I interactively place a barrier at the downstream endpoint of the edge, snapping to that WRProxyMZ point, and use TN_Temp_Barriers as the barriers, that WRProxyMZ point stopping the trace is selected in the trace results. Yay! This is the desired result.

b. If I instead place the barrier by snapping to the edge endpoint, which is spatially coincident with that WRProxyMZ point (I turned off WRProxyMZ in the table of contents to help me snap to the edge endpoint), that WRProxyMZ point is NOT selected in the trace results.

I suspect this behavior is related to what I discovered about setting flags as described in this other post, in which you need to include and populate SOURCEID and FEATUREGLOBALID attributes in the flag and barrier feature classes to get desired trace results. When you set flags and barriers interactively, those attributes are populated for you, which is why TN_Temp_Starting_Points and TN_Temp_Barriers tend to work as expected. If you're going to use different feature classes for flags or barriers, you've got to populate those attributes yourself.

This makes me wonder why the software can't just figure it out for you when you provide your own flag or barrier feature class. I don't really know why those attributes are needed in the first place. Is there some use case in which you'd want to treat a flag at the endpoint of an edge differently from a flag at a junction located at the same endpoint? The software seems to be programmed that way, which is why the above case (a) works while case (b) does not.

It would be wonderful to have some guidance on how to properly create your own flag and barrier feature classes, along with some explanation as to why things work the way they work.

JonDeRose · ‎12-07-2020

Thank you again for the clear use case and data. With your use case we were able to identify another issue and have implemented a fix related to placement of starting points in 2.7. Another issue has been created to include barrier features in the trace result when using a network junction feature class as you were doing in your initial note.

As you noted with case "a", interactive placement of trace locations using the Trace Locations pane will allow you to place starting points or barriers on an edge or junction feature. This is the default method for placing trace locations

For case "b" below, I am curious if the edge element selected is upstream or downstream of the junction feature that is not selected. If you were to interactively place a starting point at the endpoint of a line from a small scale this could inadvertently place barriers on both adjacent endpoints which could explain why the junction feature is not included in the result set. I d id notice in my testing that if I am zoomed out a bit, a barrier was placed on both the upstream and downstream edge surrounding the junction. Alternatively, you could be placing the barrier on the endpoint of the edge upstream of the junction feature alone.

Testing on my end using 2.6.3 shows that if the barrier is placed on the endpoint of the edge downstream from the junction, the junction is included in the result.

Juncitoin feature included in trace resultBarrier interactively placed on endpoint of edge downstream of the junction feature

Regarding your question about the need for SOURCEID / FEATUREGLOBALID fields when placing trace locations. We have an open issue to address some issues that are encountered when using network features (such as WRProxyMZ) as barriers in a trace. While these are honored as barrier features, there may be inconsistencies including these in the trace result as you have noticed. The alternative solution for this is case "a" as you noted above. Another approach would be use to another user defined class for the trace locations.

When placing starting points and barriers in a trace network, the SOURCEID / FEATUREGLOBALID are not required; however, these are honored if present.

Using to determine trace locations allows you to filter which features are used as trace locations. Perhaps you have a feature class that contains features you want to use as barriers; however, you only want a certain type of feature, or specific features to serve as barriers... In this case you could populate only the features you want to serve as barriers with SOURCEID/FEATUREGLOBALID information. When the trace is executed, only these features would be used as either the starting point or barrier from the class.

To clarify, case, if your class has 20 records, but only 2 have SOURCEID/FEATUREGLOBALID populated with a valid value, only those 2 would be used as starting points or barriers in the trace.

If these fields are not present, the geometry of the feature class will be used to intersect the network feature geometry and place either the starting point or barrier.

user-defined feature class used as a barrier feature

This is outlined here:

Thanks,

Jon

TimWhiteaker · ‎12-11-2020

Jon,

About case b, I was placing a starting flag at the edge endpoint, and then using the WRProxyMZ layer as barriers. When I do this, the two edges that share that endpoint are selected in the downstream trace result, while no WRProxyMZ features are selected. Thanks for the tip about multiple flags being placed when I snap to an edge endpoint. I was able to zoom in and see this. It looks like one starting flag is placed exactly at the endpoint and associated with one of the edges, and another starting flag is placed a tiny distance away, and thus a tiny distance along, the other edge. So, one of the flags is spatially coincident with the WRProxyMZ point, and another is very close by. I did try two experiments, where in one case the second flag was just upstream of the junction, and in the other case the second flag was just downstream. In both cases, the result was the same for a downstream trace (with the two starting flags, and using WRProxyMZ as barriers): the two edges were selected, and no junction was selectd. That said, I'm not too worried about case b, because for an edge endpoint, I would just create a flag associatd with the WRProxyMZ point instead of any edges.

By the way, I suspect the behavior most end users would prefer is for a single flag to be placed when snapping to edge endpoints, instead of two flags. Maybe that's one of the issues you mentioned that will be fixed in 2.7.

The issue that I could still use help with, is getting the downstream WRProxyMZ point selected when the starting flag is in the middle of an edge upstream from the WRProxyMZ point. See the first screenshot in the OP. Basically, I'm trying to get the orange point labeled 1378 to be selected in a downstream trace using the green circle, which is partway up the upstream edge, as the starting point. When you set up a trace like that in the first post, do you get point 1378 selected?

Thanks for those links about starting points and barriers. That is exactly the kind of documentation I was looking for, and I'm a little embarrassed that I didn't stumble across it on my own!

JonDeRose · ‎12-17-2020

"The issue that I could still use help with, is getting the downstream WRProxyMZ point selected when the starting flag is in the middle of an edge upstream from the WRProxyMZ point. See the first screenshot in the OP. Basically, I'm trying to get the orange point labeled 1378 to be selected in a downstream trace using the green circle, which is partway up the upstream edge, as the starting point. When you set up a trace like that in the first post, do you get point 1378 selected?"

@TimWhiteaker This behavior is one of the items that I've brought to the team for review. As a workaround, the WRProxyMZ junction will be selected in the trace result if you place the barriers interactively using the Trace Locations pane.