Talk:Proposed features/Power routing proposal

From OpenStreetMap Wiki
Jump to: navigation, search


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!

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 System-users-3.svgBahnpirat (on osm, edits, contrib, heatmap) 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 relationroute_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)
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 ( - 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 (way) 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 System-users-3.svgSurly (on osm, edits, contrib, heatmap) 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)

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 : relation 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 relation 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 : node 3915604799, node 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.
Powerline branch 1.jpg Powerline branch 2.jpg
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 relation 6087750, the only protective device is located in the source substation here area 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.