Proposal talk:Power routing proposal

route=power

Resolved: Solution chosen is type=power+power=circuit

Although I recognize the modelling need for relations describing the different connections on different power circuits on shared towers, I don't think they should be type=route+route=power. All other routes, afaik, have physical objects traversing them. Can somebody come up with other use cases for relations in the power transfer systems? Then it could be something like type=power+power=connection, but native speakers might come up with a more fitting term. Alv 12:50, 23 May 2011 (BST)

Ok so maybe we can pick up good tag values from Bahnpirat's model to the second one, more power exchange complient. Fanfouer (talk) 16:51, 14 March 2013 (UTC)

Power lines are not routes!

Resolved: Solution chosen is type=power+power=circuit

I don't like this tagging: type=route+route=power. Please don't confuse travelling routes (roads, transport routes, hiking routes) and configurations of power lines, and please don't mix one into another. I recommend to use the other type for the powerline relations, namely type=power_circuit. When we'll develop tagging of power lines well, the relation will include supporting structures (towers and poles), points of welding and so on. The relation will (and already is) essentialy differ from a typical route relation.

Agree about 'routes'. However, I would prefer to use type=power + power=circuit. Then all power related relations can have a common name space (such as "power=substation" or "power=plant" relations). The roles of members could be 'segment' (for line/cable segments), 'terminal' (for substations), 'line_tap' (for tee points = "points of welding"??). I see absolutely no reason to include towers or poles in the relation. That would lead to huge unmanageble relations with no benefits (you can directly retrieve the towers from the nodes of the line segment members). --polderrunner (talk) 15:10, 3 February 2013 (UTC)

Actually, it might benefit to add tower to the relation where several lines share the same tower. That wouldn't add much hazzle for the maintenance of the data, and could add additional information, such as level of the various lines, and whether or not they tee on the same tower. I agree that putting _ALL_ towers into the relation is pointless, but sometimes additional information can be derived that way. I have not thought about how to do it, and have not bothered to search for examples. --Skippern (talk) 16:18, 3 February 2013 (UTC)

Sometimes one tower has different reference numbering for each of the circuits that it supports. This is the case and reason to include a tower in the circuit's relation or even make a special relation for a circuit's tower in order to put the ref into such relation (if we had possibility to assign a tag for relation member, see next API proposal if would make life easier). --Surly (talk) 18:43, 3 February 2013 (UTC)

I'm still not convinced that it is needed. In northern Europe towers always have a single reference number. The individual circuits may be indicated in different ways, e.g. using coloured balls in the tower. How would you relate the different reference numbers to the circuit of the relation? You can only add the complete tower as a member, not individual tags. --polderrunner (talk) 19:46, 3 February 2013 (UTC)

I'm torn between the data size and the amount of information it will bring if we add towers to relations. The usefulness is as usual irrelevant because if we don't manage to find use cases, someone would.

I think we shouldn't have to tag such information, but we should be able to if we want it. -- Surly (talk) 08:23, 11 March 2013 (UTC)

When routing for power was introduced, I think mappers would had copied a well known model like road routing. If someone has a better tag for that I'm not against using it. The most important is to model correctly circuits among whole power grids. Fanfouer (talk) 21:58, 3 February 2013 (UTC)

Polderrunner, are you sure that such two-level tagging will be better? In any case I don't argue against your variant. I strongly argue against using of type=route in the circuit's relations. And I already have thought about tagging of segments and so on. You and I have similar thoughts. --Surly (talk) 18:43, 3 February 2013 (UTC)

Well, one advantage is that you can retrieve any power related objects just by looking for "power=*". That already works very well for ways and nodes and it would be preferable to also be able to retrieve relations using a simple query. --polderrunner (talk) 19:46, 3 February 2013 (UTC)

Good job surely :)

Would you mind if I move it to the Power transmission refinement proposal? Or maybe we can create a dedicated proposal for power routing? We would have dedicated space to document each proposition of that kind. Taking the best from the Bahnpirat (on osm, edits, contrib, heatmap, chngset com.) pov would be great too.

I'm ok with your point of view but I think there's room for improve tagging words like ref or power=circuit_segment.

Do the specialized relation power=circuit_segment is mandatory? Can't we directly add all ways to a single power=circuit relation? Fanfouer (talk) 17:09, 10 March 2013 (UTC)

> Do the specialized relation power=circuit_segment is mandatory?

Of course circuit_segment is optional. It is useful when a line splits into multiple towers. Introducing circuit_segment we can gather circuit relation members into a sequentional structure without parallel routings. Sometimes it can be useful. Can't we directly add all ways to a single power=circuit relation? -- I think, we can. But if we can make mapping more structural, more strict and more detailed -- why not?

If you believe that power routing need a dedicated proposal, than feel free to move this chapter into a proposal's page.

-- Surly (talk) 08:23, 11 March 2013 (UTC)

I share the concern about power=circuit_segment. It is making the scheme unnecessary complicated just to solve a minor problem (think of the poor data consumers having to evaluate nested relations). My pragmatic approach would be to just include one of the three line segments as member in order to get a sequential line string. Maybe not the most 'pure' way of doing it but would simplify things. --polderrunner (talk) 21:54, 11 March 2013 (UTC)

I disagree. Routing segments should be sequential, it will simplify processing and ensures that there is no rings in a linear route. That is why we accept splitting of public transport routes and introduce route_master relation. If we don't fear to embed route relations into route_master relation, I see no reason to fear embedding a circuit_segment relation into a circuit relation. --Surly (talk) 16:11, 12 March 2013 (UTC)

I'm wondering what kind of additional information it would be bring to us. Can't we add all ways to the same circuit relation? I'm aware that we won't be able to distinguish phases since there's no tags on relation members but is it useful in regard of apparent complexity? Fanfouer (talk) 22:35, 12 March 2013 (UTC)

Usually all the elements of a same voltage are interconnected within a given country. So what about relation tagged type=grid + grid=power + voltage=nnnn? Such a rerlation will include all power lines of voltage nnnn (which are connected), as well all substations between them. Plamen (talk) 07:28, 13 February 2014 (UTC)

I don't agree to say that all lines of a given voltage are interconnected. There are switches and phase corrector transformers in substation that can isolate dynamically lines from the rest of the grid. Making such a relation isn't relevant since you can retrieve all the lines (the grid) within a country with a given voltage. Power routing is here to document atomic circuits using power=line ways. Fanfouer (talk) 08:58, 13 February 2014 (UTC)

I would like to agree that use of type=route is not a very good choice. I support use of separate scheme which use type=power+power=circuit. This will allow us in the future to develop additional schemes which will be connected to each other. But I don't like in the currently proposed scheme use of trunk_circuit and branch_circuit roles, in my opinion they are clearly redundant. (but circuit_segment is somewhat necessary, so it's alright to keep it as exception) It seems it will be more elegant to keep all lines which hardwired to each other in one relation, instead of keeping them in several different ones and collect them after in master relation. Also I would like to propose to use role "line", which will be used instead of "trunk_line" and "branch_line" (in cases when one cannot or do not want distinguish between branch and trunk lines), while use of "branch_line" will be optional. Anyway I think we should create separate proposal for this scheme and keep develop it on new page.

Nothing does force you to map circuit branches. The use of power=circuit relation is sufficient to map a route in my scheme and is separated from power=branch relation. Omitting the information about circuit branching is not a trouble for routing mapping. Mapping of branching with a power=branch relation is intended for those who can and want (or need) to reflect an information which main circuit connects to which branch. Such mapping is, of cause, optional for common mapping. It is interesting mostly for special purpose of detailed maps of energy transmition (or for people with strong interest to power lines micromapping). --Surly (talk) 12:00, 16 November 2014 (UTC)

circuit dependent pylon numbers

In some cases, one single pylon has a multiple reference numbers. That can happen where two operators share the same pylons. In northern Germany, TenneT uses an individual set of pylon numbers for each circuit. As I don't see any other sensible way to add this information, there should be a role for the ref.(comment by Basstoelpel)

I think this is a rare situation (don't think it exists in either NL or DK where I'm active). I wouldn't make the proposal more complicated for this reason. Just add the multiple refs to the affected towers separated by ';'. --polderrunner (talk) 19:46, 1 June 2013 (UTC)

You shouldn't be surprised, that some thing exists that you have not seen. This practice is very common in some places. Of course we may separate refs by ';', but how can we then distinguish, which number for which circuit is? --Surly (talk) 19:15, 6 July 2013 (UTC)

You've both made a good point here. The matter is we can't tag a relation member. We could use tags including circuit object ID (like tower:6353252:ref=XX) but since OSM object don't have stable ID it's not a good idea either. IMHO that's a serious improvement to ask to devs. Fanfouer (talk) 15:37, 7 July 2013 (UTC)

The matter is we can't tag a relation member — (sigh) That is why I especially await with a hope for a next version of API that allow us to mark relation members with tags, not only with roles. Surly (talk) 22:36, 8 March 2020 (UTC)

This practice is common in Russia. Not a pylon but circuit's fixture is marked by number; every circuit that has its own reference number on the same tower (I'll upload a photo soon). That is why I'd like to establish a relation for describing a combination of a circuit, a tower and the tower's ref for the particular circuit. --Surly (talk) 19:03, 6 July 2013 (UTC)

Maybe it would be a good idea to get an overview of tower markings in different countries. Please fill in the details for your country:

• Netherlands: Tower numbers. Each circuit has a colour indicated by a coloured sign on respective sides of the tower, e.g. WIT (white) and ZWT (zwart=black).
• Germany: Tower numbers. Circuits marked by coloured balls in their respective crossarms. Occasionally towers may have two numbers when circuits have different operators.
• Denmark: Tower numbers. Circuits not individually marked as far as I'm aware.
• Russia: Circuit mounts in towers numbered, towers as such not numbered.
• France: Actually it depends. You can find towers with 2 circuits but only one reference (http://www.next-up.org/images/Valence%20double%20THT%20Pylone%20225kV%20%20122%20DSC01021%20copie.jpg - ref = 122) but others could show 2 different references (
  

  French tower with 2 different refs
  ). In that situation I'm willing to put the reference on each circuit even if it's the same.

--polderrunner (talk) 21:04, 6 July 2013 (UTC)

shortcuts in operator tag

"operator=XY Corp." or " operator=local op." are a poor idea. In addition " operator=local op." is most likely - how one decides whatever operator is local or not (etc)? Mateusz Konieczny (talk) 13:43, 19 November 2014 (UTC)

I pretty see your point. We must use operator=local op;transmission op because the power line () is supporting two circuits operated by 2 different operators.

operator=* should also apprear on the circuit relation.

However, I don't think the first point of view will stay in this proposal since Surly (on osm, edits, contrib, heatmap, chngset com.) is responsible of it. Fanfouer (talk) 17:55, 19 November 2014 (UTC)

Splitting logical from physical infrastructure

I would find interesting to stop using wires=* on this proposal.
It's a power line section's attribute and a route can go through different sections with different wires=* values.
On the other hand, frequency=* is a route's attribute and this key sounds irrelevant on a power line section.
Many routes with as many different frequency=* values can use a given section. The perfect example is train traction circuits sharing a section with 50Hz/60Hz transmission network. Fanfouer (talk) 22:31, 8 March 2017 (UTC)

The amount of cables=* of a circuit frequently varies across different sections too. —M!dgard [ talk ] 17:14, 7 April 2019 (UTC)

I don't think so, wires=* do. Although a given circuit can go along different sections with different amount of conductors, the circuit always involve the same number of cables (i.e the same number of phases for alternative current and same name of poles for direct current). This is useful to have cables=* defined on both lines and circuits to know how they're used by circuits. Example of a line with 5 conductors involved in 2 circuits, the first is three phased (cables=3) and the second is direct current (cables=2. 2+3=5, QA should be ok with that.Fanfouer (talk) 22:38, 7 April 2019 (UTC)

As far as I know the number of phases indeed remains the same, but the number of "cables" does not necessarily: at a lot of overground-to-underground transitions in Belgium, circuits change from 3 overground to 6 underground "cables", e.g. 4939083971 4939083971. It also happens in lines: at these towers the circuits go from 3 to 6 cables: 1834236975 1834236975, 1834236986 1834236986. I agree it would be nice to express how many cables are used per circuit. To map this in the general case, one would have to put exceptions in a role (which would be a hack) or use sub-relations (which would be unwieldy). —M!dgard [ talk ] 10:28, 8 April 2019 (UTC)

In OSM terminology, cables doesn't refer to physical conductors but on phases/poles. You're dealing with wires=*, not actual cables=*. A 3-phase circuits always get cables=3 but can run on line sections with wires=triple or wires=double since cables can be bundles of conductors. The underground cable you mention with 6 conductors for 3 phase should get cables=3 + wires=double.

Regarding 1834236975 1834236975, you connect cables=3 + wires=single and cables=6 + wires=single since conductors aren't bundled, despite the 6-conductors section got a bridge at its end. Such configuration is intended to maintain the whole line in operation (to detect faults even on decommissioned group of 3 conductors) more than allow transit of more power: the bay is not a bundle of 6 conductors but only 3 conductors. This is different here where the whole line is designed with a proper bundle of 2 wires for each phase (cables=3 + wires=double). Fanfouer (talk) 21:09, 8 April 2019 (UTC)

@Surly: how do you feel with that please? See this 5459752 5459752 involving two line sections, one with wires=double and other with wires=triple, thus wires=* can't be defined on the relation. If you agree, wires=* should be removed from relations and frequency=* from lines. All the best Fanfouer (talk) 17:29, 4 December 2020 (UTC)

I would disagree with removing frequency=* from the actual ways in most cases. It's not reasonable to expect mappers to check for relations which duplicate some of the characteristics of the ways. Certainly if there is a situation where there are two different circuits using the same power=line feature, then it would make sense to have frequency=50Hz;60Hz on the power=line and then separate power=circuit relations for each frequency, but I don't see why we would want to remove the frequency information from the physical feature. --Jeisenbe (talk) 19:18, 4 December 2020 (UTC)

frequency=* is not a property of a physical line (voltage and cross section are) in real life, the point isn't to duplicate information but to move it at a more accurate place. You could change the frequency of any line in a minute if you want to. Adding frequency=* on power=line is the same as adding service=tourism on highway=primary. Fanfouer (talk) 20:27, 4 December 2020 (UTC)

"You could change the frequency of any line in a minute if you want to." Right, but you can also change the frequency of any circuit in a minute if you want to. You can change a highway=primary to access=no + bicycle=yes by putting up a sign which says "Road Closed, Except bicycles", but we mark this information on the way. You can change the substance=* in a pipeline in a few hours - though it would probably be a bad idea. We mark this information on the way because that's the easiest thing for mapper to do and it's easiest to maintain in most cases --Jeisenbe (talk) 20:36, 4 December 2020 (UTC)

Access restriction on highways would be equivalent to voltage (which is a property of a physical line), not frequency. Frequency changing would be equivalent to this tourism service is over now, a commuter line will be available next month. The road won't change at all for that and we don't mention this change on the way. There are actually pipelines that handle multiple substances. This would be a situation for several relations describing every services available (with restrictions), but we didn't discussed this item yet Fanfouer (talk) 21:28, 4 December 2020 (UTC)

Power circuits can have many endpoints

I find the sentence Power lines have exactly two end point and have no "stops" in the middle confusing because we don't really understand if it deals with physical lines or logical circuits.
Later in the proposal, the specification of power relations members shows that endpoints can't be more of 2. So I conclude the above sentence deals with power circuits actually.
Anyway a common power circuit can really have many more than 2 endpoints. Endpoints are (at least) as many as connected consuming devices.
Have a look here : 6087750
Such topologies are more often seen on distribution networks than transmission and power circuits are needed on both. Fanfouer (talk) 13:47, 10 March 2017 (UTC)

I have strong doubts about it. You can't unbraid a conductor and use it to build entire grid. But you can make a T-shape connection of a branch line to a trunk line (a "power=branch" relation is intended for this case). --Surly (talk) 19:16, 10 March 2017 (UTC)

Several T-shapes connections can serve to built the circuit I put as example. Why can't we connect as many branches or transformer of substations as needed ? Fanfouer (talk) 21:14, 10 March 2017 (UTC)

It seems for me that excessive simplification happens to be in your example. Are you sure that all that branches have the same reference number and other features of the single power circuit?

--Surly (talk) 19:16, 10 March 2017 (UTC)

The circuit 6087750 actually have the reference given as SSGE7C2025 in ref:ERDF:gdo=* (national codification scheme).

It's not a collection of objects sharing a reference, this is THE reference of this circuit. It's unique at country scale.

All specific involved features have their own too : 3915604799, 180855533 and so on...

It's compliant with reality and no simplification had been made here Fanfouer (talk) 21:14, 10 March 2017 (UTC)

Let's look at these pictures.

Even if all three parts of the system had the same ref, you can unmistakable state, that LA and LB are the elements same power line circuit. LA and LB are connected to the tower's insulator at the points "1" and "2", respectively.

But the line LC is a circuit of the other power line. It is joined at the point "3" to the line LA—LB at the side. If you set yourself an aim to walk along the route of the entire power line starting from LA, then after this tower you'll certainly go along the LB part, not along the LC.

Why not along LC? Since I'm an electron and we are legion, we will certainly split ourselves to follow both LB and LC paths, according to Kirchhoff node law. I don't see any protecting or even switching device to prevent current from flowing into LC while going along LA/LB.

The purpose of my proposal is to make accurate and detailed description of power lines. As much accurate and as much detailed as possible.

As I understand rationale and as an occasional writer on it, the main goal is to map power circuits. No problem to make an accurate mechanical/physical description of power lines but it's not the same topic.

It's a problem to not have any IEC definitions linked in the rationale. I would recommend these : 826-14-01, 466-01-07.

The first one is particularly important: a power circuit got protective devices on its edges (at least the main one). Then, it's a logical object which won't refer to physical layer it relies on Fanfouer (talk) 22:23, 17 March 2017 (UTC)

In this case I'd recommend to make one relation power=circuit of ways LA and LB (you may even not divide the way at the node of this power tower); and make the other relation power=circuit of way LC. Then make the third relation power=branch to tell that LC flanks to main circuit.

I don't get the point of branching relations. Why LA-LB have to be the trunk and LC the branch? What if we set LC-LB as trunk and LA as branch? Fanfouer (talk) 22:23, 17 March 2017 (UTC)

Fanfouer, can you please make some photos of your power lines? I want to understand why you consider that branches as the same circuit. Is it only because of the same reference number or they are peer constructionally?

Sure, here you go: Distribution lines. There is actually a switch on the foreground, but it's only a typically closed mechanical switch, not a protective circuit breaker switch and then it's no edge of a circuit (at least according to IEC).

In my example 6087750, the only protective device is located in the source substation here 115223105. Then, when closed, this circuit breaker will allow power to go at any point of the relation I set as a circuit and it is topologically relevant.

Here in France, distribution operators use this structure with many endpoints in their official documents, such this one (a colour on the map = a circuit and S = protective device on circuits origins). /!\ Strictly copyrighted and can't be imported in OSM.

I agree with Fanfouer here. A branch without switches is electrically the same circuit until someone cuts the conductors. If there are switches, it could be debated. —M!dgard (talk) 18:06, 1 May 2023 (UTC)

My national TSO uses the same ref for all branches. To enable safe human communication, it would make sense to do it like this everywhere (to avoid the possibility for an electrical circuit to be de-energized while it's still connected in a different substation where it has a different ref), but conceivably some TSOs could assign a different ref at a branch point. In such cases, sub-relations will be needed. @Surly: is this the case for your TSO perhaps? —M!dgard (talk) 18:17, 1 May 2023 (UTC)

Note: I've deleted my old comments here since they really didn't add anything to the conversation. I've been using the current circuit and branch relations while working on the NGED Import Project. So far I'm created between 500 and 1000 of these relations so here's my view on this. Practically There is no situation that can be described with a power=branch relation that could not be described with a power=circuit relation with more than 2 endpoints. The only situation I can think of where separate circuits relations would be beneficial is when the branch has a different ref to the trunk but then I would argue that that if the branch has a different ref to the trunk then the ref does not describe the circuit but instead the line and should be on the power=line way instead. I've encounted a few major downsides while using these relations. In the circuits I map I very regularly come across splits where there is no distinction between a trunk and a branch which essentially forces me to fabricate information by picking one over the other. Secondly is the sheer number of relation needed to describe a simple complete circuit. take this Example that I encountered very recently (Please excuse my MS paint skills):

The optimal way to describe the circuit between these three substations using power=circuit and power=branch relations would require a total of 5 relations, 3 circuits and 2 branches. If you chose to ignore the dead-end length you could get it down to 3 relations, 2 circuits, 1 branch. However by simply allowing multiple endpoints, this entire circuit could be represented with a single circuit relation with no downsides and without the need for super relations making everything much simpler. --Kitsee (talk) 02:14, 7 December 2024 (UTC)

here is the mapped circuit relation ignoring the multiple endpoints limit for the previous example 18389368 --Kitsee (talk) 15:09, 23 December 2024 (UTC)

Make this proposal approved

As of today @Surly:, @Bahnpirat: and @Fanfouer: agree on the need to see this proposal completed and reviewed to choose the best solution to describe power circuits.
A few steps wait to be completed to end the RFC and open the proposal for voting. @M!dgard: feel free to get involved too.

• Propose a single relation pattern as to limit the complexity of tagging (without neglecting usecases)
• Move any element that doesn't match the proposed tagging to archives (as already done for similar option to transportation routes)
• Add examples and more precise guidelines to describe power circuits from ground.
• Solve existing discussion like #Splitting logical from physical infrastructure upside

I'm ok to deal with wiki writing, based upon the discussion we can have here. During the last October Hackweekend in Karlsruhe, Bahnpirat and I discussed about the two proposed options and as far I remember we agreed on describing each circuit individually and points I add below with individual chapers to help discussion. Fanfouer (talk) 22:22, 6 March 2020 (UTC)

We have discussed many use cases of this proposal. But it seems for me that, until we did not solve #circuit_dependent_pylon_numbers problem, the proposal is incomplete and not ready for voting yet. Surly (talk) 07:39, 10 March 2020 (UTC)

This proposal won't fix all issues we may have with routing and circuits references. We have to make choices and establish priorities of what is the most important. power=circuits and sections sound more key elements than the problem of circuit dependant tower reference numbers don't you?

We should limit to these two relations we are talking about as to don't confuse people with too much amount of new things and make the proposal finally approved.

We will be able to make additional proposals to solve other issues but it's more desirable to go through small steps than through a big one. Fanfouer (talk) 23:20, 10 March 2020 (UTC)

Branch relations are not necessary

Branch relations shouldn't be mandatory and can deducted from additional physical line's roles in circuit relations.
To achieve this we could replace the single line role with more elaborated values like main and branch. A given physical segment can be main in one relation and branch in another one which make the tagging way simpler than currently proposed, right? Fanfouer (talk) 22:22, 6 March 2020 (UTC)

Consider a two-circuit power line with branches . If a branch circuit's naming (ref, name or abbrev) is different from main circuit, then they must be tagged with different relations. In such case we couldn't determine which branch is connected to which trunk without introducing a relation special for branching topology.

Maybe I didn't understand your opinion, so please give your tagging version for my example of branching.

And please notice that the power=branch relation marks not a line connected to trunk, but a connection itself. Which branch circuit connects to which trunk circuit and via which point. Especially useful case is when a mapper couldn't survey a connection point but knows (and wants to map this) which circuits are connected to each other to make a branching. When I dismiss my laziness, I'll make a drawing of such case. Surly (talk) 21:37, 8 March 2020 (UTC)

I agree with you for branch references (actually, French TSO currently make branch references opendata instead of circuits ones. They are equal in case fo A-B circuit but not with A-B-C or more topologies). Shouldn't we wait (or explicitly motivate) for the API to support relation members' tags instead of defining additional relation?

To deal with connections, you may have a look to Proposed_features/Lines_management which is curently in RFC. It's more a local topology question than a circuit relation one, I think. What additional information does a power=branch relation bring that a power=circuit relation with main and branch roles doesn't? You can actually find which node do main line and branch line have in common to find the via without requiring to define additional relation with via role don't you? Fanfouer (talk) 22:53, 8 March 2020 (UTC)

I made a drawing of a simple case of branching.

The trunk is a 3-circuit power line; it has circuits "U-1" and "U-2" on one side of a tower and a circuit "U-3" on the other side. Branches named "V16" and "V17" are connected to the trunk at the point "A".

Each of 5 circuits are tagged with respective circuit relation. How can we mark that "V16" is connected to "U-1" (not to "U-2" and not to "U-3"), and "V17" is connected to "U-3" (not to "U-1" and not to "U-2")? Two "power=branch" relations help us. Both of them have the tower "A" with role "via"; one relation has a member relation "U-1" with role "trunk_circuit" and "V16" with role "branch_circuit"; the other relation has a member relation "U-3" with role "trunk_circuit" and "V17" with role "branch_circuit".

Maybe you suggest simply combine lines "U-1" with "V16" into one circuit relation, and "U-3" with "V17" into another one? Because of different naming, such merging is not possible here, the trunk and branch circuits must reside in the different relation.

Surly (talk) 09:06, 9 March 2020 (UTC)

Finally I dismissed my laziness and made a drawing of incomplete information about circuit connections.

"line1" and "line2" are OSM lines representing a power line. Circuits "U-1", "U-2", "U-3", "V16", "V17" are tagged with a respective circuit relations.

During a survey a mapper encountered an impassable area (a swamp, a fence, etc). Because of that, the connection point remained unknown and unmapped. But the mapper has recognized that "V17" is a branch of "U-3", and "V16" is connected to maybe "U-1" or maybe "U-2".

There'll be two "branch" relation. The first one has member relation "U-3" with "trunk_circuit" role, member relation "V17" with "branch_circuit" role, and with no "via" node. The second relation has member relation "V16" with "branch_circuit" role, OSM line "line1" (not a relation, but a line, pay attention to it!) with "trunk_line" and, again, with no "via" node.

With such method we are able to give maximum of available information about line connections.

Surly (talk) 09:06, 9 March 2020 (UTC)

Ok the point of describing connections and put independant references is now clear, thank you for charts. I agree that in case of branching, we need nested relations to involve physical lines in sections and sections in the whole actual circuit.

As to have a more systematic approach in tagging, would you accept to call U-1, U-2, U-3, V16, V17 circuit sections and {U-3 + V16} a circuit ? I assume a section only have physical line members while a circuit may have section relations and physical lines as members. In France, U-3 like sections split on the branch tower and any Y circuit will actually have 3 independant sections for instance (with 3 different refs). This will enable to always expect circuit relation on top of anything and only use circuit sections when required to hold appropriate references.

However, using relations to describe missing parts of physical power lines is error prone in such situations. It has to raise quality control alerts warning that apparently disconnected physical lines hold a unique circuit (or even a section). It is currently proposed with good willings to put the maximum amount of information despite something is missing but this prevent simple checks : mappers may unfortunately connect two independant lines and should expect to be warned to correct this instead of being understood as ok the mapper states there is a connection but we don't know the physical layer yet. Fanfouer (talk) 22:25, 9 March 2020 (UTC)

Circuit segments relations are not necessary

Resolved: power=circuit_segment removed from the proposal

Circuit segments relations aren't necessary as splitting phases points can be deducted from physical topology (physical segments will have different cables=* values).
It's not a power circuit matter. Can we remove it ? Fanfouer (talk) 22:22, 6 March 2020 (UTC)

We can put every single cable of splitting phases into a circuit relation sequentially. But I'm afraid that a rather dumb software interpret such routing as running there and back again in a shuttle manner. In my example (look at the simple case drawing): line piece 3, then 4, then U-turn and the piece 5 returns to the tower holding 3,4,5,6 pieces, then U-turn again and the piece 6 runs to the tower holding 4,5,6,7, then the phases gather and continue as piece 7. I agree that for a clever enough software this relation is not needed. This method of tagging splitting phases must be optional. Surly (talk) 22:07, 8 March 2020 (UTC)

You're not responsible of how software interprets tagging, especially when it's on the wrong way. Going along every single segment sequentially will break how we read single line diagrams. As said, every physical segment will hold cables=* and at each connecting node, software have to get the same amount of cables out than the amount in. No need of additional tagging. I think power=circuit_segment should not be reviewed as to not encourage to add too many relations which have to be maintained afterwards. Fanfouer (talk) 22:40, 8 March 2020 (UTC)

I agree with you. I wanted a possibility to give some hints to software. But nobody like such complicating, and no user of my proposal used it. We may explicitly state that circuit segments relations are optional thing or completely remove it from the proposal. I prefer the latter variant.

Removing this precise usecase from proposal will make it clearer. As you will read my answer in the previous chapter, you'll understand that sections relations may be useful at a more appropriate extent. Fanfouer (talk) 22:25, 9 March 2020 (UTC)

Lost history of power=route

Resolved

This proposal is really old, from 2013, and started out as a proposal for route=power - unfortunately, that tag is in use, but now has no documentation even in proposal form which is searchable, since this proposal has switched to type=power + power=circuit.

If you all are planning to move forward with this, maybe it is best to start a whole new page like Proposed features/Tag:power=circuit for the present-day proposal, and leave this page as an archive of the history? Or is it too late for that? --Jeisenbe (talk) 12:22, 11 March 2020 (UTC)

The method with route=power relation mentioned in the chapter Rationale—Tagging similar to Transportation routes. It is archived and resides now on the special page: Proposed features/Power routing proposal/Tagging similar to Transportation routes. --Surly (talk) 18:08, 11 March 2020 (UTC)

Thank you, I didn't realize that. --Jeisenbe (talk) 14:44, 12 March 2020 (UTC)

key:speisebezirk

Resolved

Given Bahnpirat (on osm, edits, contrib, heatmap, chngset com.)'s involvement here, my guess is that Key:speisebezirk is going to be replaced by the tagging proposed here? If so, would any of you guys kindly mark it as such and discourage readers from using the tag? --Kai M. Poppe (talk) 06:17, 31 March 2021 (UTC)

speisebezirk=* has nothing to do with relations or transporting energy from one point to another point. More like the postcode to adress an area (collection of ways and nodes, forming a place). This key is a place holder until a better one is found. --Bahnpirat (talk) 16:34, 4 March 2022 (UTC)

One circuit with different number of cables

Cheers! Already using this proposal, for its simplicity and for being the power routing proposal closest to being approved. Does this scheme allow mapping a circuit where the number of cables changes along the circuit? Eg, circuit 1 goes through towers A, B and C. The path A <-> B is shared by two circuits: circuit 1 and circuit 2. In A-B, circuit 1 has 3 cables, and in B-C, circuit 1 has 6 cables. Dmfr (talk) 20:47, 11 December 2023 (UTC)

Hi! Do you have pictures of such a situation? Aren't you confusing cables=* and wires=*? Fanfouer (talk) 23:42, 11 December 2023 (UTC)