Batch trace - How to get count and write this to starting points

[Jens_Dalsgaard]

Hi there

I have a feature class populated with trace starting points.

I have a trace configuration returning only meters downstream of the trace starting point.

And I am able to successfully execute a batch trace using the geo-processing tool as long as I am only returning aggregated geometries.

The result is a feature class showing downstream meters (point features) that I may symbolize by the group field (Start_ID).

So far so good. I am struggling to make the next step, though.

Hence, I actually do not need the aggregated point features.

Instead, what I need is to have the batch tracing tool count all meters encountered downstream of each trace starting point and write this count to the Meter_Count attribute (LONG) in the trace starting point feature class. 

I am aware of the documentation (https://esri.github.io/Utility-Data-Management-Support-Tools/docs/3.1/BatchTrace.html) as well as on the video-walk-through (https://esri.github.io/Utility-Data-Management-Support-Tools/help/BatchTrace.mp4). 

I cannot seem top get my head around how to actually accomplish, what I want, though.

Yeah, it comes down to ticking off the Calculate option - but after that, I am left not really finding the documentation / demonstration or with a brain unable to understand the approach.

Help, please 🙂

[VenkataKondepati]

I have couple of suggestions but not sure if they meet your situation.

Run your BatchTrace with Calculate turned on.
Set Group field to Start_ID, choose your start points as the target layer, and in the calculation setup, pick your downstream meter layer as the source, choose COUNT(OBJECTID), and write the result into the Meter_Count field. This way, when the trace runs for each start point, it will total all meters downstream and store that number directly in your start points.

If you don’t want to configure Calculate, you can still do it in two steps:
Run BatchTrace returning the downstream meters with Start_ID populated → use Summary Statistics (CASE = Start_ID) to count them → join the result back to your start points and update Meter_Count.

Both methods will give you a meter count per trace start point; the first does it in one run, the second in two simple GP steps.

Regards,
Venkat

[Jens_Dalsgaard]

I need to ask you for some clarifying questions here, @VenkataKondepati - or maybe @MikeMillerGIS should bring clarity.

The Group Field has already been set to Start_ID as described above:

This is what is already populated onto the Trace Name attribute on the generated Aggregated Points:

This really doesn't relate to the calculation as such, does it?

Now, as I want to calculate the count onto the trace starting points and not generate aggregated geometries, I disable Aggregated Results and enable Calculate:

This engages a new section in the GP-configuration, and I am asked to specify the attribute to which the calculated information is to be written:

I notice that the attributes shown come from the JD_BatcgTraceStartingPoints feature class - that's good.

But I also notice that apparently I am only allowed to write the calculated results to attributes with data type TEXT - and hence not to the intended attribute Meter_Count 

It seems I will have to update the schema but for now I just choose DisplayName as target:

I believe, by this I have set up writing trace results to the DISPLAYNAME field on the starting point features.

It is after this that it becomes blurry to me.

What do you mean, Mr @VenkataKondepati, when stating:

1. pick your downstream meter layer as the source
2. choose COUNT(OBJECTID)
3. and write the result into the Meter_Count field

I simply don't get it. 

-----------------------------------------------------------

The Fields to update drop-down reveals fields from the trace starting point feature class, so I'd assume, this is where I specify storing results on the JD_BatchTraceStartingPoints:DISPLAYNAME fields.

But - what is this compared to the Store Summary Information on Starting Points information (red ellipse above)?

Generally, this section is a complete mystery to me: 

And the built-in documentation doesn't help me out:

Assistance will be appreciated.

Best regards

Jens Dalsgaard

[MikeMillerGIS]

A text field is required, because what is stored is the result of a trace with summaries.  The result of a summary is returned as a string, like @VenkataKondepati was mentioning.  

To create a trace config with a summary(function-https://pro.arcgis.com/en/pro-app/3.3/tool-reference/utility-networks/trace.htm#GUID-C96D0B7D-9E41-4...), you need to run a trace, and fill out the summary details.  Then run Trace to Trace Config(http://esri.github.io/Utility-Data-Management-Support-Tools/docs/3.5/Trace2Config.html) or use the Add Trace Configuration with and fill out the function section(https://pro.arcgis.com/en/pro-app/latest/tool-reference/utility-networks/add-trace-configuration.htm...)

[Jens_Dalsgaard]

That the returned results must be stored in a text field is fine - I just create a string field for the result returned instead.  

I was under the impression that it was the batch trace that did the count, but now understand that it is the trace configuration doing so. So, I create a new trace configuration returning the count of low voltage meters downstream:

Trying to execute this new trace configuration (returning the count) returns an error though:

ERROR 999999: Something unexpected caused the tool to fail. Contact Esri Technical Support (http://esriurl.com/support) to Report a Bug, and refer to the error help for potential solutions or workarounds.

What am I doing wrong here?

[MikeMillerGIS]

Assume this is services?  If you turn on debug logging, does the server log provide any additional details?

That trace configuration is not complete, you just listed Count.  What do you want to count?  I am guessing there is not a lot a validation on creating a trace configuration.  Best option is to make the trace and use the Trace to Trace Configuration tool.  That way you can ensure the trace is completely working.  

[Jens_Dalsgaard]

The trace configuration is being applied against a mobile geodatabase (whilst testing stuff out).

What I want to count is the number of meters reached in the downstream trace. 

-------------------------------------------------------------------------------------------------------------------------------

Let me start by first add a trace configuration returning downstream meters as a selection:

The above trace configuration correctly return the downstream low voltage meters as a selection:

All good so far.

___________________________________________________________________________________

Next, let me add a trace configuration returning the COUNT of downstream meters only:

Now, this is where I get lost ;):

What I aim to count is the number of low voltage meters reached - blue rectangle. 

But, should I fill out any of the parameters with yellow highlighting above? And if so, should I simply count occurrences of an arbitrary network attribute, that I know will be filled out?:

And how about Result type?

???

Hope for further patience on my fumbling around here 🙂

Perhaps even a video walk-through ...

[MikeMillerGIS · Accepted solution]

Output has no affect on functions/summaries.  Output is strictly a filter of the result selection set.  You need to set up the function to count the meters.  I like to use Network Categories for this.  So create a category for the items you want to count.  Then set up the Function to Count/ObjectID or some other field on the device class, really does not matter, Categoery isEqual Meters

[Jens_Dalsgaard]

Thanks for taking the time to clarify this, Mike.

So batch tracing requires you to create and assign a network category (or network attributes?) to the asset types to be counted?!?

Aiming for a more flexible way to analyze the grid, the way ahead might doing regular tracing returning JSON and then following up with custom analyzes on this output set.

Now I now. 

[RobertKrisher]

@Jens_Dalsgaard Even outside of batch tracing, its a good idea to have network categories set up for the important types of features you care about. I use them all the time when setting up traces to focus on particular features of interest (medium voltage conductors, transformers, etc). I like them primarily for the following reasons:

• They let me identify a feature using a single network attribute, instead of needing to rely on the network source, asset group, and asset type. I prefer this not only for simplicity but also slight performance gains (which is important when you're doing a lot of these).
• They allow me to write code based on an abstraction (network category) instead of a physical implementation detail (asset group/type code). This makes my solution more portable.
• Because network categories can be applied to multiple asset types, this also gives me flexibility. I can assign/remove categories from different asset types to get the desired results in my report without needing to change any code.
• Being able to configure behaviors instead of hard coding checks for custom codes is especially important when you consider how much flexibility customers have with their data models and how much work it can take to update and deploy an add-in, script, or server component.