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; } } }

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 🙂

Trouver plus de publications taguées avec

Accepted answers

MikeMillerGIS

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

All comments

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:

pick your downstream meter layer as the source
choose COUNT(OBJECTID)
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-460B-B45C-F3FDFDAFAB45), 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#GUID-C96D0B7D-9E41-460B-B45C-F3FDFDAFAB45)

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 ...

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.

Jens_Dalsgaard

Fully agree, Robert.

Yet, working with utilities I bet you know that not all questions are fit for standard configurations.

Network categories is for standard config's and we are currently working with Elvia til finalize network categories and attributes. This - counting downstream meters - is a standard question.

For more ad-hoc questions, other approaches likely will be pursued.

RobertKrisher

@Jens_Dalsgaard Ah yes, solving for the ad-hoc scenario. Ideally, you set up network categories (and even trace configurations) to cover 80-90% of your use cases (doing this at the asset group level is a good start).

Then, a user needs to fine-tune the results in an ad-hoc trace that isn't already covered the user can add additional conditions to cherry pick specific asset types. Network Source, Asset Group, and Asset Type are all network attributes that you can include in conditional expressions on v6 or later networks. Setting up network categories for asset groups lets you skip having to make the user memorize network source ids and subtype codes which are not easily discoverable to an end user.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

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