|
IDEA
|
I don't see the option for moving the idea as suggested - please elaborate: Anyhow, I will forward your answer "there's not much research required on the JavaScript side" to our developers
... View more
a week ago
|
0
|
0
|
126
|
|
IDEA
|
Providing a product tailored to streamline grid editing and planning (Volue Grid Planner) we have a need for identifying split operation when a user splits a cable or an overhead line. Grid Planner is provided SaaS and uses the ArcGIS Javascript SDK. The justification behind this need is as follows: Following the planning of grid edits, the DSO needs a budgetary input / extract based on edits performed in the plan. How much cable, how many poles, ... Any new cable created in the plan (version) must be purchased. Yet, when splitting an existing cable one part retains its original ObjectID whereas the other part (the shorter line segment) is a 'new' feature getting a new ObjectID. With no way of catching the split, we cannot identify this new feature as 'not new but rather the result of a split). And hence the budgetary delivers a faulty output, since noone has to purchase a cable already there but just split in two What would we like Esri to provide to allow better business support? When executing a split operation through the ArcGIS Javascript SDK we need some way to identify the 'new' feature (the part after the split getting a new ObjectID) as the result of this split. The Split Method (Feature) provided in the ArcGIS Pro SDK returns 'The ObjectIDs of newly created features from the split operation.'. Split Method (Feature)—ArcGIS Pro This seems like exactly what is needed, as this would allow us to identify the 'new' feature as 'not new but rather the result of a split'. I will be available for further discussions if needed
... View more
3 weeks ago
|
0
|
3
|
235
|
|
POST
|
Using ArcGIS Pro v 3.5.2 I'd say it now works. Below you see a distance trace starting from the green trace starting point. In this trace I stop the trace at a certain network category, so it doesn't run 'the other way'. Here the distance is set to 425 meters: Here the distance is set to1,475 meters: Here the trace configuration used: This is where I set the trace to stop after a certain distance having been reached: And here I specify that I want the trace to only return cables and overhead lines. PLUS, and this is important, that I want the trace to be returned as an aggregated geometry (rather than as a selection).
... View more
09-05-2025
02:34 AM
|
1
|
1
|
1324
|
|
POST
|
We have answers that I needed. Thank you. Brief comment on my way out. All the devices and the bus-bar are already contained in another structure complying to CIM and ERP requirements. It is not possible / desirable to change this. So, now wanting to also 'group' certain devices and bus-bars in some substations, the challenges are: We cannot use containment associations from this new compact equipment asset type since devices may only have one containment parent (makes sense) We cannot use structural attachments to this new compact equipment asset type since structural attachments do not work directly against line features. I had hoped, we could do a mix Structural attachment associations from the compact equipment to the devices AND containment association from the compact equipment to the bus-bar This is not supported, so we will do with structural attachment associations from the compact equipment to the devices and then either do without any relationship to the bus-bar or simply allow adding the bus-bar GlobalID as a manually entered attribute reference on the compact equipment. Thank you for the ping-pong.
... View more
09-02-2025
11:57 PM
|
0
|
0
|
400
|
|
POST
|
Not sure, I understand the suggested approach. You suggest ? using an electric device asset type to represent compact equipment and then make J-J connectivity associations to all devices and line features being part of the compact equipment? That would bypass all existing connectivity! What am I not getting right here?
... View more
09-02-2025
03:42 AM
|
0
|
0
|
456
|
|
POST
|
Initial note - this is not the Esri electric data model yet the white paper data model as released and documented by Elvia and Volue. Gain access to this white paper on how to implement utility network for balanced three phase distribution grid. Working with Norwegian DSO, Elvia, and Danish DSO, N1, substations and their interior are documented with great detail. Below is an example of a medium to low voltage substation. In the middle you see two MV/LV transformers. Everything above is medium voltage, and everything below is low voltage. Focusing in this context on the medium voltage part, what you see are two medium voltage bus-bars - one with two (three, one idle) line-bays (connected to cables) and a bay connecting to the other, right-hand side bus-bar. The other, right-hand side bus-bar holds two transformer-bays (connecting to the two transformers respectively. Within these bays you see switches, fault indicators, current transformers, etc. - individual features each representing a function in the grid Whereas in the map each switch, fault indicator, etc. is documented as individual point features, in real world what is here many features may come a one preconfigured unit - we call it a compact-equipment. Imagine the below subset of the shown substation being one compact equipment that is craned in as one gas-insulated unit. To facilitate this we are aiming to document the Compact Equipment unit as a structure junction object in utility network. This structure junction object asset type is registered as a structure (role type) and corresponding structural attachment rules support relating a compact equipment to all the device features. This all works very fine. Now, we need to also establish a relationship from the compact equipment to the bus-bar. Yet, according to this Esri documentation structural attachments are not supported against line asset types: Feature restrictions—ArcGIS Pro | Documentation Not stopping for anything, we got a new idea. We keep the structural attachment relations to all the devices (point features) as described above And then we add to this containment associations from the compact equipment to the line feature (the bus-bar) We cannot use containment associations for all relationships to the compact equipment, since point features / devices may only have one containment parent, and the devices are already contained in another container (a substation hierarchy) containment. But, that's OK - we can live with using structural attachments to the devices and then handle the bus-bar through a containment association (because line feature do support several containment parents). SO, we register the compact equipment asset type as container (as well) and add corresponding rules allowing it to contain bus-bar asset types: Yet, when applying the asset package, we get this error message: Is it because: We apply the asset package using an oooold ArcGIS Pro (v3.1.4)? Will using a newer version of ArcGIS Pro fix this? An asset type (the compact equipment) cannot be both a structure or a container? we are not smart enough? We cannot find answers in available documentation.
... View more
09-01-2025
10:50 PM
|
0
|
4
|
515
|
|
POST
|
The thing about SMEs are, that they are likely to want solutions capable of solving all their problems - who wouldn't want that 🙂 The thing is, that just as saying I want a Lamborghini I have to match my craving with my capabilities. Am I (and the other family members) capable of driving / managing such sports car. Are my financial situation ready for the price that comes with such beauty? As a trusted advisor (I assume, that's your role) you must highlight the capabilities of a full implementation of utility network. As outline the capabilities and limitations of simpler implementations. They will want all capabilities. And then you need to also balance this - or have the SMEs balance this - with data maturity today, organizational maturity today. Assuming they will emphasize the need to grow as organization and hence move from where they are now to become a more mature organization you will likely agree. But you must then ask the SMEs the put forth a plan for how to deliver on this transition. How will they deliver the higher, consistent, and needed data quality - what money and what resources? A plan that must be backed by their management. By doing so, as trusted advisor you present them with opportunities and challenges, and help the organization on their path towards streamlining business processes. You move from 'simply doing IT / UN' to engaging in change management.
... View more
08-19-2025
04:36 AM
|
2
|
0
|
298
|
|
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
|
108
|
|
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
|
565
|
|
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
|
576
|
|
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
|
590
|
|
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
|
614
|
|
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
|
11
|
798
|
|
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
|
598
|
|
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
|
1364
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 09-05-2025 02:34 AM | |
| 2 | 08-19-2025 04:36 AM | |
| 1 | 01-31-2023 08:01 AM | |
| 1 | 10-28-2024 08:22 AM | |
| 2 | 10-21-2024 03:45 AM |
| Online Status |
Offline
|
| Date Last Visited |
Monday
|