Latest Contributions by Jens_Dalsgaard

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

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

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