Which data models for power transmission circuits?

[François Lacombe]

Hi Openmod

French power transmission cartography taskforce on OpenStreetMap is about to complete the mapping of power transmission circuits over physical opendata provided by RTE.

To be sure we understand the same thing, to us, a circuit is a metallic continuity involving 2 or more substations. See : https://www.openstreetmap.org/relation/6106033

Such data is currently only available on crowdsourced platforms until operators provide official records.

I'm about to industrialise the daily publication of the complete list, with or without geographical data, of French power circuits.

I wonder what should be the best data model/format for that. Have you already think about it ?

It can be a simple geojson with lines and polygon of substations or a table linking several substations nodes with mechanical or electrical figures deducted from lines involved in the circuit.

Feel free to contact me if you have hints on this topic

All the best

François Lacombe

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux

[Tom Brown]

Hi François,

From my perspective the most useful thing would be a table (e.g.
comma-separated-variable file) that contains for each circuit:

- names of connected substations

- geocoordinates of connected substations

- voltage of circuit

- length of circuit

- information on whether the circuit is overhead or underground

- information on conductors if available (e.g. number of cables in the
bundle for each phase, information on aluminium/steel cross-section)

- information on the tower configuration if available (number of
circuits on each tower, whether there is room for additional circuits on
the tower)

- operator name if available


This information is then sufficient for anyone to reconstruct the
electrical parameters of the circuit:

https://wiki.openmod-initiative.org/wiki/Transmission_network_datasets#European_50_Hz_transmission_lines


The SciGRID project also provides example data tables for lines and
substations:

https://www.power.scigrid.de/pages/downloads.html

They did a lot of work on deciding and consulting on the data format.


Do you think this work on mapping the circuit relations could be
extended to the rest of Europe / the world? The coverage in Germany is
already very good.

Best wishes,

Tom

> *François Lacombe*

>
> fl dot infosreseaux At gmail dot com

> www.infos-reseaux.com <http://www.infos-reseaux.com>
> @InfosReseaux <http://www.twitter.com/InfosReseaux>
>
> --
> You received this message because you are subscribed to the Google
> Groups "openmod initiative" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openmod-initiat...@googlegroups.com
> <mailto:openmod-initiat...@googlegroups.com>.
> To post to this group, send email to openmod-i...@googlegroups.com
> <mailto:openmod-i...@googlegroups.com>.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/openmod-initiative/CAG0ygLeONCwv98wSgYRWdr2kV1M31vRcOqA3FvKv82d8sW1nVg%40mail.gmail.com
> <https://groups.google.com/d/msgid/openmod-initiative/CAG0ygLeONCwv98wSgYRWdr2kV1M31vRcOqA3FvKv82d8sW1nVg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
Karlsruhe Institute of Technology (KIT)
Institute for Automation and Applied Informatics (IAI)

Dr. Tom Brown
Research Group Leader, Energy System Modelling

Phone: +49 721 608 25737
Fax: +49 721 608 22602
Group website: https://www.iai.kit.edu/english/ESM.php
Personal website: https://nworbmot.org/

Visitor Address:
Office 309
Campus North Building 445
Hermann-von-Helmholtz-Platz 1
76344 Eggenstein-Leopoldshafen

[François Lacombe]

Hi Tom,

Thank you for your input.

It's ok to produce a table, even a csv file with some wkt geometries

My views under each attribute you propose below :

Le sam. 2 févr. 2019 à 10:42, Tom Brown <tom....@kit.edu> a écrit :

- names of connected substations

- geocoordinates of connected substations

- voltage of circuit

- length of circuit

All of them are ok and very often known

 

- information on whether the circuit is overhead or underground

It can be both, it's a physical line property. The circuit can go through several sections whether overhead or underground, insulated or not.

- information on conductors if available (e.g. number of cables in the
bundle for each phase, information on aluminium/steel cross-section)

Same, it's a physical line property.

See this one involving two overhead sections with 3-wires bundle and 2-wires bundle

https://www.openstreetmap.org/relation/5459752 (look at cables attribute on line segments members)

 

- information on the tower configuration if available (number of
circuits on each tower, whether there is room for additional circuits on
the tower)

Physical property, with many possibilities for a single circuit.

 

- operator name if available

Ok for this one

How should I deal with physical line attributes ?

Should I provide an aggregated list of values or skip them?

Nice links to SciGrid and Openmod i'll look at to improve the details

Do you think this work on mapping the circuit relations could be
extended to the rest of Europe / the world? The coverage in Germany is
already very good.

Power relations are currently under normalization in OSM community but they are already used worldwide.

So it will certainly be scaled to all networks.

Discussions are going there :

https://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal

All the best

François

[Tom Brown]

Hi François,

Firstly can other people on the list, particularly folk at SciGRID and
osmTGmod, please double-check we're not missing any important aspects?
This is incredibly important if it sets the standard for the open data
we use for power grids across the globe.

@François: You're right, we need to specify the segmentation more
explicitly.

T-junctions etc are also a problem for the tabular format.

I'd suggest to keep as much information as possible, so that people can
decide themselves how to handle it. How about a double-indexed format,
with the first index being circuit, and the second being segment?

For example just with the wires as an example for a T-junction:

| circuit_name | segment_name | from | to | wires |
|--------------+--------------+--------------+--------------+-------|
| circuit_23 | segment_1 | substation_4 | node_5 | 3 |
| circuit_23 | segment_2 | node_5 | node_6 | 2 |
| circuit_23 | segment_3 | node_6 | substation_6 | 2 |
| circuit_23 | segment_3 | node_6 | substation_7 | 3 |


By the way that relation is a good example of the challenges here:

https://www.openstreetmap.org/relation/5459752

The cables / wires / circuits attributes are jumbled along the line so
you get

| way | cables | wires | circuits |
|-----------+--------+--------+----------|
| 100500807 | 3 | double | |
| 100497456 | 6 | double | 2 |
| 479158213 | 6 | triple | 2 |
| 214450522 | 3 | triple | |
| 100494414 | 6 | triple | 2 |
| 100494422 | 3 | triple | |

I guess it's a double circuit, but some of the segments look like single
circuits.

François, many thanks for all your efforts on this! It's really very
much appreciated in our community.

Best wishes,

Tom

On 02/02/2019 18:57, François Lacombe wrote:
> Hi Tom,
>
> Thank you for your input.
> It's ok to produce a table, even a csv file with some wkt geometries
>
> My views under each attribute you propose below :
>
> Le sam. 2 févr. 2019 à 10:42, Tom Brown <tom....@kit.edu

> <mailto:tom....@kit.edu>> a écrit :

> --
> You received this message because you are subscribed to the Google
> Groups "openmod initiative" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openmod-initiat...@googlegroups.com
> <mailto:openmod-initiat...@googlegroups.com>.
> To post to this group, send email to openmod-i...@googlegroups.com
> <mailto:openmod-i...@googlegroups.com>.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/openmod-initiative/CAG0ygLftsgDEcauQx4KxLNJ3HFBiR8eU4xnxywVtxhvfxsieTA%40mail.gmail.com
> <https://groups.google.com/d/msgid/openmod-initiative/CAG0ygLftsgDEcauQx4KxLNJ3HFBiR8eU4xnxywVtxhvfxsieTA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[François Lacombe]

Le sam. 2 févr. 2019 à 20:15, Tom Brown <tom....@kit.edu> a écrit :

@François: You're right, we need to specify the segmentation more
explicitly.

T-junctions etc are also a problem for the tabular format.

Exactly, I always forget them in first thoughts :)

Here you go for a T-relation 225kV

https://www.openstreetmap.org/relation/6901347

 

I'd suggest to keep as much information as possible, so that people can
decide themselves how to handle it. How about a double-indexed format,
with the first index being circuit, and the second being segment?

What about a geojson file with each circuit=1 feature with MultiLineString geometries for connecting lines?

Each relation would get a single feature and proper attributes.

Main issue I see is that such a feature won't allow to put attributes on a given physical line segment.

Then a more conventional table would be enough.

As physical lines attributes go in additionnal columns on each corresponding file line, I can add the wkt geometry in another column too

 

By the way that relation is a good example of the challenges here:

https://www.openstreetmap.org/relation/5459752

I guess it's a double circuit, but some of the segments look like single
circuits.

The circuit shares most of its length with another circuit on the same towers.

At some points, individual 3 cables lines goes from one tower to another.

Have a look to this very nice place

https://www.google.fr/maps/@46.0523157,5.8250159,3a,76.5y,102.21h,107.49t/data=!3m6!1e1!3m4!1snCgxHEqYXW0M0IawUpB0tw!2e0!7i13312!8i6656

https://openinframap.org/#16.95/46.051948/5.827715

 

François, many thanks for all your efforts on this! It's really very
much appreciated in our community.

You're welcome

All the best

François

[arjuna...@wupperinst.org]

Dear Francois and Tom,

just some hints from an osmTGmod perspective:

In our view a T-Junction are three individula circuits, connected to one bus (which is the junction (tower) and not a substation) and three different substations. (Or even more if you have more than one T-Junction) So every circuit has just two buses, which is easier to handle and it even has to be implemented like this in every grid-calculation software.

We have three main tables, one for buses, one for substations and one for connections (circuits)

Apart from names and unique ids (we always use the ids of osm) you will need:

For every circuit:

*From bus (or substation)

*To bus (or substation)

*Type of connection (e.g. cable, overheadline, transformer)

*Voltage

*Number of cables

*Frequency (Very important and not yet mentioned, you have to disinguish at least between 0 Hz, 16,7 Hz and 50 Hz)

*Number od Wires (as described here: https://wiki.openstreetmap.org/wiki/Key:wires, but it is not always unambiguous)

*Geometry (as multilinestring) (If you have this information, you can calculate the length and do not have to have an own column for it)

*Topology (as linestring)

For every bus or node you need at last:

*voltage

*frequency

*to which substation they belong (if any)

*geometry (point)

And if you want to represent the substations as unique elements, you would need for them:

*voltage (multiple voltages shall be possible)

*frequency (muliple frequencies possible)

*geometry (Polygon)

(*geometry_center (point))

An additional note:

It would be great to have a column linking the circuit dataset to the pulished datasets of the TSOs. For example this here from the German TenneT: https://www.tennet.eu/fileadmin/user_upload/The_Electricity_Market/Transparency/static_grid_model/2018_statisches_netzmodell_ttg__1_.csv (I know, that there is still a licence issue here)

Feel free to have a look at https://github.com/wupperinst/osmTGmod even though, i haven't worked on the code for a while.

Best

Arjuna

[François Lacombe]

Hi Arjuna,

Thank you for your interesting insight

Le dim. 3 févr. 2019 à 14:15, <arjuna...@wupperinst.org> a écrit :

In our view a T-Junction are three individula circuits, connected to one bus (which is the junction (tower) and not a substation) and three different substations. (Or even more if you have more than one T-Junction) So every circuit has just two buses, which is easier to handle and it even has to be implemented like this in every grid-calculation software.

Understood and this is compatible with what we currently do on OSM.

Our model should nevertheless be reworked to create Link relations connecting substations and buses. Current OSM circuit relations would involve those new link relations (and not physical lines nor substations).

We admit that a link between a substation and another bus should be a relation since several consecutive lines and cables sections can be involved in the link.

See : https://www.openstreetmap.org/relation/8384687

The voltage should be distinguished between design voltage (physical lines property, the max voltage the line is built for) and the operating voltage (logical property, the voltage at which the circuit is actually operating).

Operating voltage should be equal or under design voltage. Operators often give the operating voltage. This point isn't currently clear on OSM.

Here is a 225kV sharing some 400kV sections : https://www.openstreetmap.org/relation/6100028

 

We have three main tables, one for buses, one for substations and one for connections (circuits)

Got it, I'll look forward to produce compatible tables.

Apart from names and unique ids (we always use the ids of osm) you will need:

For every circuit:

*From bus (or substation)

*To bus (or substation)

*Type of connection (e.g. cable, overheadline, transformer)

This one shouldn't be a link/circuit property. According to above hypothesis, a link can involve several different sections.

Nevertheless we have line=bay to be more specific with internal substation wiring.

*Voltage

Operating voltage (if known)

*Number of cables

*Frequency (Very important and not yet mentioned, you have to disinguish at least between 0 Hz, 16,7 Hz and 50 Hz)

*Number od Wires (as described here: https://wiki.openstreetmap.org/wiki/Key:wires, but it is not always unambiguous)

*Geometry (as multilinestring) (If you have this information, you can calculate the length and do not have to have an own column for it)

*Topology (as linestring)

For every bus or node you need at last:

*voltage

*frequency

*to which substation they belong (if any)

*geometry (point)

And if you want to represent the substations as unique elements, you would need for them:

*voltage (multiple voltages shall be possible)

*frequency (muliple frequencies possible)

I'm not sure frequency should be a property of substations.

You will get more and more converter substations which operate at several frequencies, and this makes requests harder.

It occurs I remove frequency=* from physical lines when available on circuit relation.

I know Germany or Switzerland have physical lines shared between TSO and train traction operator hosting circuits operating at different frequencies.

This topic is currently under discussion with extra attributes to be added on substations : https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_functions

 

*geometry (Polygon)

(*geometry_center (point))

An additional note:

It would be great to have a column linking the circuit dataset to the pulished datasets of the TSOs. For example this here from the German TenneT: https://www.tennet.eu/fileadmin/user_upload/The_Electricity_Market/Transparency/static_grid_model/2018_statisches_netzmodell_ttg__1_.csv (I know, that there is still a licence issue here)

Good point.

OSM already have some keys to add operator internal references, to begin with ENTSOE EIC : https://wiki.openstreetmap.org/wiki/Key:ref:EU:ENTSOE_EIC

Here comes codes for French RTE (French only) : https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:RTE

We also write some documentation about French DSO codes (French only) https://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo

 

Feel free to have a look at https://github.com/wupperinst/osmTGmod even though, i haven't worked on the code for a while.

Thanks, definitely I will :)

Let's keep this thread up, all the best

François

[Bourboul syranidis]

Hello,

At first, thank you for all the great efforts!

I would like to ask a question about T-junctions. Could it be that there are cases that such nodes are only geographical junctions but not network nodes?

For instance, although it's not so clear, https://www.openstreetmap.org/node/1050580684 might be such a case, where OSM data suggest that there is a cross topology of 3 double-circuit lines but if you check the respective picture from google maps it seems that it's rather a triangle of 3 single circuits that are not connected at that node. In that case, probably the node should be replaced with three different nodes that are not connected and each circuit be mapped as a separate way and part of a separate relation. But I guess this becomes too complicated, right?

Kostas

[François Lacombe]

Hi

Thank you for this big tower use case :)

We've got the pretty same here

https://www.openstreetmap.org/node/1218747115

Ways only describe the physical layer, i.e 3 double-circuits power lines and indeed it misses logical information about how power actually runs over cables.

Relations help to get how connections are made, there are 3 involving this node :

https://www.openstreetmap.org/relation/6492541

https://www.openstreetmap.org/relation/6492540

https://www.openstreetmap.org/relation/6492542

So this node isn't actually a T-junction.

In case of actual T-junction like here :

https://www.openstreetmap.org/node/951678824

There is only one relation and the Y is clear : https://www.openstreetmap.org/relation/6170186

The current issue is the node isn't member of the relation (this is pretty easy to fix, with a role like 'junction').

Branches of the Y aren't properly described (you can see that the last example involves two 2-circuits branches). We miss relations for each branches as I understood the first answers.

This still wait to be fixed with a nice workaround.

All the best

François