Improve transmission coverage of HIFLD dataset when source data are missing

[danielolsen]

🚀

• Is your feature request essential for your project?

Describe the workflow you want to enable

I wish we had a way to add transmission lines to areas where there it is known to be missing.

Describe your proposed implementation

One relatively simple way to achieve this could be a user-supplied list of substation coordinates and transmission lines connecting them, which would get appended to the original HIFLD data before further processing. An algorithm to create synthetic information would be nice, but much more difficult.

Additional context

See New York City:

[danielolsen]

New York City is especially tough because so much of the electrical network is underground, so the location of substation and any transmission lines that connect them is unknown. On the data side, we may be able to use subway stations as a proxy, since their locations are more well-known and station density should roughly correlate with density of electrical consumption.

[danielolsen]

See also: Chicago

[danielolsen]

Currently within #267, we add the ability to add arbitrary substations to the source data. In the same way, I believe we can add arbitrary transmission lines, once we determine which substations and transmission lines we can use as a proxy.

[danielolsen]

Interestingly, there's more coverage of substations within these areas as compared to transmission lines. Even before adding proxy substations, we should be able to add proxy lines that connect to these real substations to distribute the cities' demand a bit better.

[BainanXia]

@danielolsen Does it imply the real lines connecting those real substations are actually underground?

[danielolsen]

Probably. The HIFLD transmission line dataset has some underground lines, but the coverage seems much spottier than the overhead ones, either due to data availability or some strategic decision about which data should be shared (or something else entirely).

[danielolsen]

Another fun one from looking at Texas:

These two 138 kV transmission lines do seem to connect in reality, although in the April 2nd 2022 version of the dataset they don't. There are 345 kV lines in the same corridor, and on the right there's a substation at the end of the line that the 345 kV and 138 kV lines all connect to, but on the left side the 138 kV line seems to dead-end at this substation while the 345 kV lines pass right on by without stopping. The 138 kV line is double-circuit double-conductor, so there's a lot of power that it could potentially be carrying across this gap, but isn't.

[danielolsen]

I'm going to use this Texas example to build a framework where user-supplied proxy lines can get added to the known lines from the HIFLD dataset. I think this design should be flexible enough to be able to intake proxy lines that are a combination of user inputs and algorithmically-defined proxies.

[danielolsen]

#289 adds the ability for manually-defined lines which get added to the existing lines, using the following information for each line:

• from substation and to substation
• voltage
• number of circuits
• number of conductors

Before the new add_proxy_lines function is called which combines the lines defined in const.py with the lines from the original HIFLD dataset, the set of proxy lines could be expanded by e.g. identifying a set of substations which need to get connected and running a minimum-spanning-tree algorithm to identify the shortest paths to connect them, and adding new lines of a chosen design between them. A minimum spanning tree is probably not the true topology, but it would be a fairly simple starting point. It seems that finding the edges to add to a graph in order to make the graph biconnected (i.e. removing a single node doesn't increase the number of connected components) with minimum total cost is known as 'biconnectivity augmentation' and is solveable in polynomial time, but at first glance I don't see that algorithm within NetworkX. I see https://networkx.org/documentation/stable/reference/algorithms/generated/networkx.algorithms.connectivity.edge_augmentation.k_edge_augmentation.html#networkx.algorithms.connectivity.edge_augmentation.k_edge_augmentation which is related but different and apparently NP-hard.