Proposal talk:Lines management

More examples?

Resolved: Not all situations could have a clear management pattern Fanfouer (talk) 15:05, 30 March 2020 (UTC)

Wow a lot of work, so far. Btw, I found some interesting pictures. Is there any way to classify the objects on these picture examples (see table below) also within this proposed scheme? :-) --MalgiK (talk) 21:05, 10 January 2020 (UTC)

Those funny poles actually exist but it's not said that OSM can easilly address them as they support numerous different lines. As always in such situations OSM hardly manage to describe such complex things (let's do the same with antennas). I put notes in the table to try to help, but this proposal is first of all intended to propose simple concepts that could be mixed with Matrix_values help.

I should add that a management pattern don't have to be always determined Fanfouer (talk) 00:28, 11 January 2020 (UTC)

Thanks for watching, responding & adding some table details. I just wanted to show, that there isn't obviously everywhere an easy tagging possible. --MalgiK (talk) 23:21, 11 January 2020 (UTC)

Photo	Location	Tagging	Note
	Japan	power=? line_attachment=? line_management=?	These are mostly line_attachment=anchor but a management pattern can't be determined on that picture.
	Japan	power=? line_attachment=? line_management=?	line_attachment=anchor for MV line on top
	Japan	power=? line_attachment=? line_management=?	line_attachment=anchor for MV line on top
	Ecuador	power=? line_attachment=? line_management=?	line_attachment=pin for MV line on top
	Cambodia	power=? line_attachment=? line_management=?	line_attachment=anchor for MV line on top

Consider loops as branches

Resolved: branch and loop has been clarified and no intersection exists between them both Fanfouer (talk) 15:05, 30 March 2020 (UTC)

Let's consider the situation described with the chart on the left : one power system connects to another one on a particular tower and both come from the same origin.
This matches the branch definition as well and loop value may be confusing in case of connecting patch going along a similar direction than the incoming line.
As to make things really clear, should we merge loop and branch values? Fanfouer (talk) 21:41, 17 March 2020 (UTC)

I don't quite understand the descriptions of line_management=branch:

"Former undocumented key branch:type=* had a value for connections between several power lines coming from the same direction: loop.

"It is proposed to consider them as branches due to such situations where 3 lines connect to the same support and look like a loop but shouldn't be described this way."

What does this mean?

It was actually a mistake, I've removed that section and found a better definition for actual loops and branches.

A branch : any Y connection

A loop : a termination connecting exactly two power circuits.

That's way simpler and examples have been updated accordingly. Fanfouer (talk) 00:29, 28 March 2020 (UTC)

Another part says:

"tower:type=branch ( + branch:type=loop) -> to be replaced by line_management=branch"

"Two or more independent circuits are connected in the same direction to maintain a dead part of the network under a positive voltage"

What's a dead part of the network? What do you mean by positive voltage? Can voltage be negative? --Jeisenbe (talk) 01:03, 27 March 2020 (UTC)

A dead part of the network : a line that supports no power transit, energized or not.

Domestic example: you plug your toaster in the socket, the cable will be energized but still dead: no transit runs in it. Then you press the button and the cable goes live: power runs in it until the toaster goes off.

Voltage can actually be negative but it's a convention regarding polarity. + => - wil be > 0 and - => + will be < 0 for a load.

A dead part can still be maintained energized as to detect any fault caused by surrounding trees or damaged supports even if it doesn't carry any transit any more. Fanfouer (talk) 00:29, 28 March 2020 (UTC)

But how does a mapper recognize this? I thought the proposal was about how the cables (wires) are connected to a tower or pole or at another connection point. You cannot tell if a cable is live by looking at it. --Jeisenbe (talk) 01:17, 28 March 2020 (UTC)

Mappers aren't supposed to recognize or even know where dead parts are. A loop is a visible thing as drawed on the picture. The point was only to give information to know why such loops are useful. Fanfouer (talk) 23:26, 28 March 2020 (UTC)

Value cross or crossing?

Resolved: use cross Fanfouer (talk) 15:05, 30 March 2020 (UTC)

The "proposal" section says there is a value "cross", but some of the examples use "crossing". Which is correct? --Jeisenbe (talk) 01:09, 27 March 2020 (UTC)

The cross is correct, thank you Fanfouer (talk) 00:31, 28 March 2020 (UTC)

branch:type not documented?

Resolved: undocumented removed Fanfouer (talk) 15:05, 30 March 2020 (UTC)

While it's true that branch:type=* doesn't has its own page, I think that stating it's undocumented is a little bit misleading. The values are explained on power=tower in section 2.3.--TOGA (talk) 23:27, 29 March 2020 (UTC)

I agree this could be misleading. undocumented has been removed. Nevertheless, we miss so much relevant point regarding branch:type=*: origin, motivations, applicable geometries, description... Fanfouer (talk) 15:05, 30 March 2020 (UTC)

branch vs. tap

Resolved: Both are fine. In the end it's probably just a matter of taste. --TOGA (talk) 22:24, 21 April 2020 (UTC)

Could you maybe explain why you've chosen branch over tap? In my opinion branch is the more generic term describing different configurations. For example split to me is a type of branch.--TOGA (talk) 23:33, 29 March 2020 (UTC)

branch was infered by 601-02-10 IEC definition of connected side line. I could have use 601-02-29 as well. As branch/tap involve connection in their definitions and split doesn't, split won't be considered as a kind of branch as it's about two or more independant lines which change of direction.

I didn't understand why branch:type=* consider split as a subtopic instead of completely different one. Fanfouer (talk) 15:05, 30 March 2020 (UTC)

From the perspective of the individual power circuits I agree with you. But I think branch:type=* takes on a different perspective and also considers how we record the situation in the data. Two power circuits sharing the same towers are mapped as one way and when they branch out in different directions, they split into two seperate ways. That's also why there's cross as a value. The tag sees the tower as a whole, remember branch:type=* is a subkey of tower:type=branch.--TOGA (talk) 10:39, 31 March 2020 (UTC)

Important question: why tags should reflect something we already know by looking at topology? I now understand why many disconnected cases rely on tower:type=branch, thank you. Don't you think it's more desirable to know a connection exists or not where topology can't bring this distinction actually? line_management=split/line_management=split = no connection while line_management=branch means Y-connection.

We'll have so many occasions to bring up subkeys to qualify each situations of line_management=*. I think providing a flat key giving all main situations we find is more valuable than branch:type=* Fanfouer (talk) 19:54, 1 April 2020 (UTC)

Additionally, it may be possible to change line_management=branch for line_management=tap if this sounds more correct. Fanfouer (talk) 19:56, 1 April 2020 (UTC)

Considering the existing tags, I would indeed favour tap. This should also ease the transition once the proposal gets adopted. If we would start from scratch, I'd probably be 50/50 on branch vs. tap, but we don't and for me this tips the balance toward tap.

Have you maybe contacted other mappers of power infrastucture, who preferably have used the old tags in the past? It might be valuable to get a wider field of opinions on this.--TOGA (talk) 12:54, 2 April 2020 (UTC)

I'd be ok for tap too. We can ask @Bahnpirat: and @Mueschel: as they already use line_management=branch in Germany. Thank you guys to make valuable testing of proposed keys :) Fanfouer (talk) 22:35, 2 April 2020 (UTC)

I'll mark this as resolved. While I do slightly favour tap over branch, both are fine. Unfortunately we don't really have a way to do votes on matters like this, so I'll leave it at that.--TOGA (talk) 22:24, 21 April 2020 (UTC)

Definition of loop

Resolved: Loop value has been removed Fanfouer (talk) 17:06, 20 May 2020 (UTC)

Your definition of loop significantly differs from the original one on power=tower and I don't see any reasoning why that's the case. Do you have any sources that could support this change?--TOGA (talk) 23:40, 29 March 2020 (UTC)

To me and following the recent updates, I understand the current branch:type=loop definition as this picture.

As we defined branch as any Y connection to be simpler for mappers and consistent with other topologies, current loop definition sounds more like a branch and not an actual loop.

loop is only applicable for mocking a termination like this unless I could have completely remove it. Fanfouer (talk) 15:05, 30 March 2020 (UTC)

No, there seems to be a misunderstanding on your side. Loop is deduced from "looping a line in & out of a substation". This discussion has pretty good graphics explaining the situation. There's at least one case of this in your example section. The picture with the alleged 4 splits shows actually two loops, see also the location on OpenInfraMap.--TOGA (talk) 10:19, 31 March 2020 (UTC)

Wow, I indeed completely mistaken the sense of branch:type=loop (such things would require a formal page of documentation... I was reproached for making mappers guess visual properties 10x simpler than that!). But... why a topology pattern have to be mentioned on a ponctual support instead on the power circuit relation?

Knowledge of such patterns is an important point actually and I don't downgrade it. But poles, towers or any punctual feature aren't the right place to describe this while we intend to define a strong tagging model for power routing with relations.

Point of this proposal is to qualify local physical situations regarding supports and lines configuration. It has to be independent from network topology, as mappers only see a given support on ground. line_management=loop only regards this. Then then proposal has been updated to replace branch:type=loop by line_management=split, relatively to this case. Fanfouer (talk) 17:46, 31 March 2020 (UTC)

Yeah, I can understand both points of view. The loop value can be tricky with its current definition.

A question regarding your picture (not the schematics): Wouldn't this situation be better described with line_management=branch and location:transition=yes according to the second schematic for branch and the comment in the description of split? I also wonder if we should differentiate between taps where lines go in different directions and those where the tapped line stays on the same towers. Maybe parallel or by-pass could be an option?--TOGA (talk) 11:24, 1 April 2020 (UTC)

Understood. As to avoid any confusion with actual looping topologies, it may be great to change line_management=loop to line_management=bridge which also matches the use case. I can do this change depending on how you feel with it.

The picture you mention was poorly edited and I intent to remove the transition. There are only two power lines connected on the tower. If you find a similar situation with a transition, line_management=branch + location:transition=yes would be the correct option indeed.

It's true many proposed line_management values could be completed with subtags. This will be adressed in further proposals as to not overweight the current one Fanfouer (talk) 18:02, 1 April 2020 (UTC)

Yes, reusing an existing tag with a different definition should, in my opinion, be avoided if possible and bridge seems also good.

Two follow-up questions regarding your edited picture: Number one, have you seen such a configuration in real life? I'm wondering, how much influence your initial misunderstanding of the old definition of loop had in creating this picture.

Second, how would you tag the situation in the original picture? The right circuit would warrant line_management=termination but the line/cable transition of the left circuit rules this out according to your proposal.--TOGA (talk) 14:40, 2 April 2020 (UTC)

I did see such situation on ground but now I can't remember where and I don't find any picture, obviously. I'll ask a few question to appropriate people and get back here.

Regarding the original situation, I'd tag it as a split as it's the most suitable value. You may disagree, but if we don't consider such situation as a split, this would also lead to values like line_management=--no_value_for_straight_line--|termination and should be avoided. Note that it's consistent with cables=3 and cables=6 respectively on cable and line connected to this tower Fanfouer (talk) 22:52, 2 April 2020 (UTC)

If it doesn't cause too much inconvenience, a real picture would obviously be great. But I believe you, so it isn't a must-have.--TOGA (talk) 21:29, 3 April 2020 (UTC)

I hope I'd be able to find again the situation corresponding to line_management=loop or I'll remove it otherwise. Fanfouer (talk) 22:44, 3 April 2020 (UTC)

I've finally removed the loop value due to lack or proper example on ground and comprehensive work done on other values to absorb other situations. Fanfouer (talk) 17:06, 20 May 2020 (UTC)

Transitions

Resolved: transition and composed values has been introduced Fanfouer (talk) 23:36, 16 April 2020 (UTC)

Mixed cases are definitely a problem. Similar case is a double circuit line where only one circuit has a tap. If we could solve this, it would be a massive benefit over the old scheme. Just throwing out some ideas: Have you thought about incorporating transition as a value into this proposal? Also, with turn:lanes=* we currently use none as a value, might this be an additional option? The picture then would be line_management=transition|termination and my example with the tap could be tagged line_management=none|branch/tap. --TOGA (talk) 21:29, 3 April 2020 (UTC)

Yes I thought to add line_management=transition but it would collide with location:transition=* which is used on man_made=pipelines and telecom cables as well. line_management=transition|termination would worth a try I think. I don't find location:transition=yes + line_management=transition so acceptable, do you?

none value is also a good idea, but I'd consider more representative ones: simple or straight. Additionnaly, split shouldn't be combined as line_management=straight|split as the split regards all lines attached on a given support. Fanfouer (talk) 22:44, 3 April 2020 (UTC)

Yes, location:transition=yes would indeed be superfluous. Didn't you want these proposals to be applicable beyond power lines? So telephone cables shouldn't be a problem, right? Pipelines are a little different, with a great deal of good will one could argue pipeline and line_management is a sufficient connection, but it's probably not perfect.

line_management=straight|split would definitely be nonsense. More interesting is something like a split combined with a tap (see for example this tower tower). There this might make sense.--TOGA (talk) 21:33, 6 April 2020 (UTC)

Ok to consider line_management=* implementation on pipelines (later, not in this proposal). line_management=branch would be useful on pipe T connections as well.

Just ot be sure, how would you tag such situations with line_management=transition? To me it's currently a regular split with a location:transition=yes. Fanfouer (talk) 23:40, 12 April 2020 (UTC)

I agree that pipelines need more consideration and should probably be looked at seperately.

With regards to your example, I see two options line_management=simple/straight|transition or line_management=split|transition. The latter would require split being applicable to both multiple circuits or the whole tower and single circuits. But considering the tower I linked above I think this is needed anyway. That being said, I'd also argue that transition already implies some kind of split. So I don't necessarily think your example needs split and the first option should be enough.--TOGA (talk) 10:38, 15 April 2020 (UTC)

Then I've added transition and straight. For sake of consistency with split definition, I assumed that any situation corresponding to (top view) -----x==== is an actual split. Fanfouer (talk) 23:36, 16 April 2020 (UTC)

Yeah, I'm fine with that, looks good. I also made a small change to the Example section, hope that's ok.--TOGA (talk) 20:17, 17 April 2020 (UTC)

Great. There was indeed a mistake on the transpose example, thank you for correction. I've filled the completion matrix as well. Fanfouer (talk) 22:23, 17 April 2020 (UTC)

Know poles, not wires

Note here in Taiwan (e.g., wooden) pole location data is public access, but not any information about the wires they carry. Jidanni (talk) 02:58, 2 April 2020 (UTC)

We have the same here in Free too about towers without knowledge about lines attachment/management. This is even more valuable to get this information from ground then. Fanfouer (talk) 22:30, 2 April 2020 (UTC)

Combination of termination and split

Resolved: Definition is clearer for split/termination and straight/termination Fanfouer (talk) 15:29, 29 April 2020 (UTC)

Does termination really correspond to the description of split, "going towards different paths"? When a line terminates at a tower, there is no going towards anywhere, it just stops. So line_management=termination|straight should be the better option? The currently used graphic is also more suitable for that combination.--TOGA (talk) 21:58, 21 April 2020 (UTC)

split is also defined in OSM as a connection between line segments with different values of cables=*. line_management=termination|straight may correspond to a 2 circuits line with left circuit disconnected on a given support : =====_===== vs =======------ (line_management=termination|split). Do you agree? Fanfouer (talk) 23:52, 21 April 2020 (UTC)

But a connection between line segments with different numbers of cables isn't exclusive to split, that could also be branch. Your case is interesting and I agree that this is definitely line_management=termination|straight. The differentiation between those cases could be made with cables=*. If you want to use these tags, you have to analyse the connecting line segments with regards to the number of their cables anyway, see for example the potential cases with branch.

If you want to stick with split, I'd recommend to at least change the graphic, so that it fits better into the pattern of the other graphics containing a split. As it is now, it might be confusing for some.--TOGA (talk) 13:13, 23 April 2020 (UTC)

Nice, I've updated the composition table with appropriate line_management=termination|straight situation and according split charts.

However I'm wondering if updating all split charts with an optional grey line as beside would be relevent?

Presence or not of this second circuit doesn't change anything to the situation and could be helpful to be more representative to mappers

This example regards line_management=split|branch. Fanfouer (talk) 00:03, 27 April 2020 (UTC)

Adding that option to the graphics with split is definitely a good idea. My only slight worry would be that it might get to complicated, but I think it should be ok. Speaking of complicated, I think adding circuits=* to the table isn't necessary and only introduces clutter diminishing its readability. Maybe add something like "For the purpose of these examples each line represents a single circuit. Parallel lines are mapped as a single with circuits=2." to the text above the table if you want to make that clarifaction?--TOGA (talk) 11:55, 29 April 2020 (UTC)

Great, I've updated the pictures accordingly. Indeed circuits mentions were too heavy in the table and I've removed them, thnak you Fanfouer (talk) 15:29, 29 April 2020 (UTC)

Nice, from my point of view everything looks fine now.--TOGA (talk) 20:23, 3 May 2020 (UTC)

Thank you for your time, tagging schema is really better now. I'm waiting for the end of lockdown in France to solve the loop case and it will be ready . Stay safe until voting Fanfouer (talk) 17:38, 5 May 2020 (UTC)

Level composition matrix confusion

I've never really understood this section of the proposal. I was hoping this would be clarified since it still seemed to be under discussion:

"Level composition matrix

"As many situations exists in reality, it can be useful to combine (line_management=value1|value2) some values to reflect what actually happen on a given support level according to compatibility rules introduced upside. "This table indicates situations corresponding to left value in rows and right value in columns. "Each line refers to an independant line system (a circuit, for power lines, 3 cables in alternative 3-phases system). Black ones are mandatory and grey ones are optional elements which don't change the value selection if they exist. "All parallels lines are draw with a single OSM way in practice with appropriate cables=* and circuits=* values. "You won't see cross as it can't be combined with any other value for a given level."

"Left & right are established following common principles of OSM."

This is not clear. I imagine "left" and "right" refer to the sides of the way if you look along the way direction. But which one comes first in the value?

Thank you to have noticed this, it was forgotten along edition. I've replaced line_management=value1|value2 by line_management=left|right Fanfouer (talk) 22:33, 22 May 2020 (UTC)

Ok, that's what I expected. But the new text is not totally clear. The example 'line_management=left|right" could be mis-interpreted as an actual tag. In the later documentation I would suggest providing real tag examples like "line_management=branch|transition", and change the "variables" to something like line_management=<left side>|<right side> perhaps? --Jeisenbe (talk) 22:45, 22 May 2020 (UTC)

line_management=<left side>|<right side> is relevant and I've updated the text Fanfouer (talk) 14:33, 24 May 2020 (UTC)

What if there are 2 circuits separated vertically?

It regards different levels and currently focus has been put on a single support level. See "Real life chart section" : "Further thinking is required to address complex situations, as line management can mix several configurations on different tower levels." Fanfouer (talk) 22:33, 22 May 2020 (UTC)

Is the proposal suggesting to use a vertical line as the separator instead of a semicolon?

This proposal relies on Matrix values pattern so yes. It is already widely used to document highway lanes for instance or more recently with line_attachment=*.

Semicolons regards lists while matrix/pipes regards tables. Pipes split cells and parenthesis group rows. Fanfouer (talk) 22:33, 22 May 2020 (UTC)

So "line_management=branch|straight" would be used when there are two circuits and one goes straight at the tower, another branches? --Jeisenbe (talk) 22:07, 22 May 2020 (UTC)

Yes, on the same level. Fanfouer (talk) 22:33, 22 May 2020 (UTC)

Should we really deprecate such a common tag?

• I have comments but abstain from voting on this proposal. Should we really deprecate such a common tag? --Floridaeditor (talk) 12:30, 25 May 2020 (UTC)

This proposal doesn't propose to deprecate tower:type=* but only some values used in combination with power=tower.

Values proposed for replacement are used on ~13k power=tower while billions and millions towers left to be mapped or completed worldwide on OSM. It doesn't sound like a really common tag.

Proposed tagging will allow to get uniform terminology regarding lines topology whatever their support would be.

Have a look to this diary explaining what is going on with line_attachement=* which already allowed to describe more power supports than tower:type=* had ever done.

Finally, at the point we're able to provide consistent tagging for a given concept, I'm standing against :type suffix I find irrelevant. Fanfouer (talk) 18:15, 25 May 2020 (UTC)