Subnetwork coloring

572
1
10-26-2022 04:18 AM
Status: Open
Jens_Dalsgaard
Occasional Contributor

For a meshed network subnetworks meet at open breaking units (as well as at the subnetwork controller).

Typically having a subnetwork per transformer (for three winding transformers we would even have two subnetworks) very quickly an electric utility will end up having tens of thousands of subnetworks.

Each of the subnetworks (Subnet Lines) generated will have a subnetwork name together with a few other attributes (https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/subnetline-feature-class.htm).

Coloring Subnet Lines offers a quick overview of how the grid is fed and where tie breakers exist.

Yet, coloring the many thousand subnet lines (coloring by subnetwork name, what else can I do)) we get this warning:

JensDalsgaard1_0-1666781689481.png

Well, I have to click Yes to have some sort of useful coloring. 

Besides likely not being nice to performance having coloring based on a very large number of unique values, we also quickly see the problem: Adjacent subnetworks (subnet lines) are assigned colors very alike (or perhaps the same).

In the screen dump below, the green arrow indicates a place where adjacent subnetworks are assigned contrasting colors whereas at the red arrow two adjacent subnetworks are assigned the same color: 

JensDalsgaard1_1-1666782254614.png

 

My propsal to Esri is, that when updating subnetworks, you also assign a coloring-number to each subnetwork (an extra attribute to be added). Not a color code (#3380ff) - just a number from 1 and up. Then I may choose whether 1 is represented by red, green, ...

In a previous proof of concept, I showed that the entire low voltage grid (real world data for a low voltage grid feeding several hundred thousand customers) could be colored using less than 15 colors (it's years ago - I don't recall the exact number - it was less).

As the utility network is persisted in a graph, without being an expert on these matters I believe such coloring-numbers could be easily generated using the so-called graph edge-coloring: 

https://en.wikipedia.org/wiki/Edge_coloring 

This way I could symbolize my subnet lines based on not thousands of subnetwork names but based on less than 15 coloring numbers. 

And I would be sure that adjacent subnetworks would be assigned contrasting colors; It's quite a lot easier to define 15 contrasting colors than to do the same with thousands...

 

1 Comment
JakeJacobsAVA

We have similar scenarios in our gas network with Isolation Subnetworks. (Although we merely have thousands, not tens of thousands to deal with). I appreciate @Jens_Dalsgaard suggestions for generating a set of colors that are non-adjacent.  However, I am also interested in maintaining stable color assignments to the same networks over time. 

Since subnetworks are split or added one by one over time, a small number of subnetworks have colors assigned or adjusted after the initial colors are assigned.

The way we have approached this is to add a color field to the subnetline featureclass but also maintain a separate table with the subnetworkname, tiername, and color. This table is editable. There is an attribute rule in the subnetline.color attribute to copy it from the separate table if the subnetline row is updated or created.

This allows us to generate colors using python or whatever we like but also to manually adjust or add if someone finds a color that was generated to be not optimal.  This is all because the subnetline is not directly editable.

Note that we don't have a good user interface for editing this table at present. If Esri were to implement this solution, I would expect that would be part of the need - a way for users to pick the colors they want or to calculate or recalculate a color for all the subnet lines or a portion of them - whether this was on the subnet line or in a standalone lookup table.