nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Follow up to the Gravity Network Tracing

Brian_Colson

@RobertKrisher I have a follow up question from Gravity Network - Basic Configuration.

Seems like the only way to get a digitized direction trace to work, with an associated junction, is to have terminal configurations configured within the network. Is that accurate?

Do your terminal configurations need to match the upstream and downstream naming conventions in some manner?

Otherwise, you have to create the "artificial pipe" to create the connectivity, which we had but added associations in our utility network migration.

Just wondered. Thanks.

Vind meer berichten getagd met

Accepted answers

MikeMillerGIS

Brian,

I tested tracing with digitized direction across associations. I am not seeing an issue.

Here are two examples, lower one has a controller at the start

also tested going through a directional terminal device, no issue

Red Arrow is a directional terminal device

All comments

MikeMillerGIS

Brian,

I tested tracing with digitized direction across associations. I am not seeing an issue.

Here are two examples, lower one has a controller at the start

also tested going through a directional terminal device, no issue

Red Arrow is a directional terminal device

Brian_Colson

Thank you @MikeMillerGIS . We will test it on our side once we get there and see how it goes. Thanks!

RobertKrisher

@Brian_Colson Digitized direction does not consider associations to be a directional connection (i.e. the from/to objects aren't considered to be upstream or downstream). You're more likely to run into situations where associations are causing too much to be returned.

Consider the case of an irrigation channel with a series of side gates and laterals. If you have associations from the centerline of your channel to each side gate, then every time you do a digitized direction trace along the channel it will always pull in the gates from the channel. In the case of an irrigation system this would be appropriate for a downstream trace (because the water is going to flow to that gate) but in the case of an upstream trace this isn't entirely accurate (because water isn't flowing from that gate to the channel).

Let me know if you want me to draw a picture.

Brian_Colson

Thanks @RobertKrisher . That is the exact scenario we are trying to resolve, as we have centerlines of canals, and junction / junction connecting to those centerlines as associations. Basically, the opposite of your outfall example you had in the gravity network post, so no additional drawing is needed. The problem is that we do not have terminal configurations currently demarcating upstream and downstream, which is why we previously had the "artificial" pipes.

We will continue to test this out in a proof of concept (POC) and make sure we have it configured correctly. We need to get some infrastructure upgraded first, but it is coming very soon. Thanks!

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.