|
POST
|
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.
... View more
08-15-2025
05:15 AM
|
0
|
0
|
1334
|
|
POST
|
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.
... View more
08-13-2025
01:47 AM
|
0
|
0
|
1985
|
|
POST
|
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 ...
... View more
08-12-2025
06:51 AM
|
0
|
1
|
1996
|
|
POST
|
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?
... View more
08-11-2025
11:10 PM
|
0
|
3
|
2010
|
|
POST
|
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
... View more
08-11-2025
12:23 AM
|
0
|
0
|
2034
|
|
POST
|
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 🙂
... View more
08-08-2025
02:04 AM
|
0
|
10
|
2397
|
|
POST
|
Hi there, I have a question from my team that I hope someone on this brilliant forum can answer. When a device is modeled in the Utility Network (UN) and has multiple terminals in the underlying graph, it appears to create a self-reference in the trace output. For example: "connectivity": [ { "viaNetworkSourceId": 9, "viaGlobalId": "{6E9B4C19-D497-4E20-964A-57B8B11CBC6F}", "viaObjectId": 8935, "viaPositionFrom": 0, "viaPositionTo": 1, "fromNetworkSourceId": 9, "fromGlobalId": "{6E9B4C19-D497-4E20-964A-57B8B11CBC6F}", "fromObjectId": 8935, "fromTerminalId": 31, "toNetworkSourceId": 9, "toGlobalId": "{6E9B4C19-D497-4E20-964A-57B8B11CBC6F}", "toObjectId": 8935, "toTerminalId": 32 } ] From my observations, this self-reference occurs only when a device has more than one terminal. When a device functions as a node (e.g., an EnergyConsumer) and has only a single terminal, I have not observed this behavior. Instead, all connected edges point to the same terminal. It seems as if the internal connectivity of the device is explicitly modeled when multiple terminals exist. I need confirmation that this behavior is consistent across all devices with only one terminal—specifically, that a self-reference will never occur in such cases. Can you confirm if this is a general rule? My additional question: Does this 'self-reference' represent the 'internal connectivity' within the device? Best regards Jens Dalsgaard
... View more
03-31-2025
04:43 AM
|
0
|
2
|
1357
|
|
POST
|
Following Esri Inc recommendations, which is typically wise, and using partitioned tiers for your electric grid, there might be a way around your need for 'denoting each LV asset with EHV, HV and LV tier it belongs to'. The answer, I believe, lies in in not actually writing the EHV- and HV tier names onto the low voltage feature yet still offering this information to the end user using attribute (Arcade) expressions - results of an Arcade script appearing to the user just as any other attribute in the popup. https://developers.arcgis.com/javascript/latest/sample-code/popuptemplate-arcade/ You would then add such Arcade attributes revealing the names of the EHV- and HV tier feeding the LV tier feeding the relevant feature.
... View more
02-06-2025
10:53 PM
|
0
|
0
|
3246
|
|
POST
|
Reading some of your other posts, I get the impression that you're already well into UN. You have a fully functional UN and 'simply' want to replicate this. Or what. My answer was given - sorry about that - based on the assumption that you thought - as I do find some thinking - that you can simply move data into ArcGIS UN and utility network will work. You're not there. 🙂
... View more
01-20-2025
06:00 AM
|
0
|
0
|
2452
|
|
POST
|
Re-reading your question I ask myself whether you're actually asking about migrating from one UN database to another UN database. In that case, why wouldn't you use standard ArcGIS GP's? E.g. https://doc.arcgis.com/en/arcgis-solutions/latest/tool-reference/utility-network-package/export-asset-package.htm
... View more
01-20-2025
01:35 AM
|
0
|
0
|
2470
|
|
POST
|
Migrating to ArcGIS Utility Network is COMPLEX and it seems unlikely that a dump will accommodate ArcGIS UN requirements. A dump at best would be the start of a migration process where data is transformed to comply to UN requirements.
... View more
01-20-2025
01:31 AM
|
0
|
2
|
2472
|
|
IDEA
|
Referring to this ArcGIS Utility Network Question https://community.esri.com/t5/arcgis-utility-network-questions/connectivity-trace-setting-up-combined-condition/m-p/1569491#M4697 I hereby suggest a change. In the above-mentioned question, @MikeMillerGIS states that the behaviour is as designed. I urge a change in this design then, so that setup condition barriers may work across all tiers rather than only within the initial tier. I honestly do not see when I would want condition barriers working only on the initial tier, yet when changing the behaviour so that condition barriers may work across tiers it should be simple to add this as an option (Condition barrier working only on initial tier - yes/no). Happy New Year to everyone out there
... View more
01-05-2025
11:06 PM
|
0
|
0
|
618
|
|
POST
|
Certainly, I have sent you a mail allowing you to immediately test what works and what apparently seems to not to be working.
... View more
12-16-2024
11:40 PM
|
0
|
0
|
2208
|
|
POST
|
Creating network categories and assigning these as relevant to asset types representing cables and overhead lines works out - to some extent. For example - I have created a new network category Volue_LV_OHUG and have assigned this to low voltage cables and overhead lines asset types. And setting up a named trace configuration doing a connected traced yet using this network category (Volue_LV_OHUG) as conditional barrier seems to work as intended. the trace stops at low voltage cables and overhead lines. But if I create a named trace configuration (or simply perform a trace) downstream from a medium voltage trace starting point to continue into low voltage (because I want the low voltage part of the substation included in the trace result) yet using the same network category as a conditional barrier the trace still seems to continue into the low voltage grid. What should I look for when debugging?
... View more
12-16-2024
07:57 AM
|
0
|
1
|
2233
|
|
POST
|
Of course, obviously. Should have seen this myself. Despite this, do you see any arguments against adding an idea for allowing grouping as was my initial proposal? Adding categories will work fine in this specific case, yet in may other cases it would seem unflexible.
... View more
12-12-2024
08:23 AM
|
0
|
0
|
2271
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 03-03-2026 05:24 AM | |
| 2 | 02-26-2026 02:15 AM | |
| 1 | 09-05-2025 02:34 AM | |
| 2 | 08-19-2025 04:36 AM | |
| 1 | 01-31-2023 08:01 AM |
| Online Status |
Online
|
| Date Last Visited |
Tuesday
|