Latest Contributions by Jens_Dalsgaard

‎03-17-2023

Hi @RichardKoch I agree with the GIS not being and ADMS / OMS framework rather a repository for as-built grid documentation and normal switching position. Yet, offering a more flexible subnetwork mgmt approach of (erroneously) multi-fed parts of the grid would also support better debugging - where is the missing tie-point. I had brief talk with R Krisher yesterday, and based on this, I believe we will create functionality aiming at supporting the debugging of missing tie points. Because this is needed. Also, despite ADMS / OMS offering the live switching status handling (and more) I do see a potential for using GIS for handling live switching statuses of the extensive low-voltage grid as we see many utilities having their ADMS / OMS handle medium / high voltage only. For this we are looking into creating products delivering what subnetwork management functionality does not support.

‎03-13-2023

Utility Network supports subnetworks fed from multiple subnetwork controllers [SNC's] assuming these all have the same subnetwork name assigned. In case of multiple SNC's feeding the same area, features being part of such subnetwork will have an attribute listing all the SNC controller names feeding the area. Yet, if if more SNC's feed the same area, and these SNC's have differing subnetwork names the subnetwork (line feature) is not generated - and error is generated only. When this happens, a user will need to debug the cause. That is, most likely find the switching device that should have been opened to serve as a tie point. This task would be quite a lot easier, if the user had the subnetwork line feature to look at in the map. Assuming that ArcGIS does all the needed tracing to find the inconsistent SNC subnetwork names, it would be really nice, if UN actually returned the feature representing the illegal subnetwork line. Why not return a subnetwork line feature flagged as "Illegally fed from multiple SNC's with inconsistent subnetwork names." Such improvement would offer a lot of value also during daily operation. Esri tends to show examples where a portion of the grid is temporarily de-energized (opening a switching device) to then be energized again (closing another switching device (a in effect often feeding from other substation). That is not how any DSO would do. You would not de-energize the grid, rather feed it from both sides temporarily to then shortly after to open a switch to once again make feeding 'correct'. It would be very useful to show the temporarily multi-fed part of the grid in a special color making everyone aware that a temporary situation exists.

‎02-28-2023

OK, so even we wanted to add to parents we couldn't. well, that clears any concerns 😉 Not possible. Does that go for devices only?

‎02-28-2023

The assembly b is not optional. Yet, allowing ALSO associating device c directly to assembly a (whilst also associating device c to assembly b being associated to assembly a) serves a specific purpose. You're right - it is not really circular in nature; More parallel association chains. So Esri, would this be problematic?

‎02-28-2023

Hi there Assume I have associations stating that assembly A contains assembly B in turn containing device C will having assembly A also contain device C directly (somewhat circular references) be allowed / problematic? Best regards Jens Dalsgaard

‎02-17-2023

Oh, yeah - the answer is obvious with your reply, Robert. You cleared my vision. Thanks. And Mike - we're not immediately planning on connecting the edge object to any features in the map. The immediate objective is to group line features. But now that you've asked, I think I should ask Elvia about this. It would actually be obvious to connect this edge object to assembly features delineating it (using JJCA's). Thank you guys for swift answers. See, got a lot more out of asking than looking myself 😉

‎02-16-2023

Hi there The edge objects tabular line representation (without any actual line geometry) may be used to document e.g., individual fibers in a fiber cable. In this case the edge objects will be contained. You may say the edge object in this case inherits the geometry of the container. Is it possible to have an edge object act as container containing e.g. electric cables? Yeah I know - I could do a quick test, but asking here is quicker 😉 and might even bring knowledgeable input to me. BR JD

‎02-06-2023

According to Mike, classes must be m-enabled. But you don't have to do anything with the m-enablement. At least, we don't, and still it works like a beauty. Maybe, we'll end up using the m-enablement further down the line, but for a start we don't.

‎01-31-2023

Have experience in electric utility and UN only. Yet, I am quite sure, that m-enablement is NOT needed.

‎01-31-2023

I would say, that the answer to this depends very much on the maturity of the existing ArcGIS geometric network data. If it is simpler grid representation with simpler business process support, then simpler migration tools / objectives may be used. If on the other hand the source represents a true digital twin supporting advanced business processes, then you should aim for something with more capabilities hence delivering immediate business value generation upon migrated data. Allow me to refer to a post on what I mean when speaking of digital twin: https://www.linkedin.com/pulse/migrating-arcgis-utility-network-jens-dalsgaard/ Best regards Jens Dalsgaard

‎01-26-2023

No offense. I think you should have some technical writer do this explanation. Someone not having your deep understanding 😉 This sentence requires a higher exam in negation interpretation: The item specified in the row will not be added or applied to the output when this category is unchecked only if it is not set to Evaluated in any other category that is checked on.

‎01-16-2023

Stacked Junctions is likely the error (dirty area) that you will encounter with such data. UN is unforgiving on this (as it is with duplicate vertices, self-intersecting lines, etc.) You will need to create a program that displaces some of these features (e.g., an inch into the air) whist maintaining correct connectivity.

‎11-30-2022

Will do so through the Elvia Premium Support (as it is related to / documented on Elvia UN data). Thanks for feedback, Mike.

‎11-26-2022

OK, thanks for the feedback, Mike. Where may I read more on this bug, and what is the priority / time-frame on fixing it?

‎11-23-2022

By the way - allow me to mention that performing a similar downstream trace from the HV/MV transformer in a migration from a different source using the exact same asset package template the trace propagates nicely into the low voltage mesh. Hence, I doubt it has anything to do with the schema / data model configuration.

Online Status	Online
Date Last Visited	Tuesday

My Ideas

Latest Contributions by Jens_Dalsgaard

Re: Handling multi-fed subnetworks with differing Subnetwork names

Handling multi-fed subnetworks with differing Subnetwork names

Re: Will circular associations be problematic?

Re: Will circular associations be problematic?

Will circular associations be problematic?

Re: Edge objects acting as container?

Edge objects acting as container?

Re: Do features need to be M-enabled for Utility Network compatibility?

Re: Do features need to be M-enabled for Utility Network compatibility?

Re: Migration from Geometric to Utility network requirements

Re: Utility Network Foundation solutions: Defining a subset of the model

Re: How to deal with Junction and Device-Features with the same geometry

Re: Inconsistent trace results

Re: Inconsistent trace results

Re: Inconsistent trace results

Re: How to use Error Inspector's Zoom To and Pan T...

Re: Electric Radial Partitioned Tier Source– Why A...

Re: Distance trace - how to?

Re: Choosing the right model for your stakeholders...

Re: Migration from Geometric to Utility network re...

European Utility Network Community (UNC)