Proposal:Lines arrangements

Line arrangements proposal
Proposal status:	Approved (active)
Proposed by:	fanfouer
Tagging:	line_arrangement=* Data item
Applies to:
Definition:	Consistently describe how lines bundles are arranged (vertical, horizontal, delta...) around a given support or way point
Statistics:
Draft started:	2023-04-17
RFC start:	2023-04-29
Vote start:	2023-06-21
Vote end:	2023-07-05

Following line_attachment=* and line_management=*, this proposal aims to describe how lines bundles (see rationale below) are arranged around their supports or way points.
It's kind of the line cross section shape. They can be horizontally, vertically or even arranged as a delta shape.

Corresponding definitions are took from IEC 60050 466-05 section for overhead power lines.

This proposal follows the work began in 2018 about overhead power lines modeling. Some views about it are found in this diary.

Proposal

It is proposed to introduce line_arrangement=* to describe how aerial or underground lines bundles are arranged, particularly when such arrangements are mandatory for line proper operation.
Such knowledge is notably valuable for bare power lines for which conductors arrangements should ensure insulation at all times. It is also known as conductors configuration.

It will be used on aerial lines supports (man_made=utility_pole, power=pole, power=tower...) or underground lines/cables way points and only valid on nodes.
The new key is applicable for all bundled lines that are arranged, not only power ones.

Possibles values will be horizontal, semi_horizontal, vertical, semi_vertical, triangular, square, delta, unarranged. It will default to unarranged.
See the tagging section for a complete description with respective compatibility.

As a side impact, line_management=transpose definition should be adapted to remove arrangement word in it as to not confuse anyone, because conductors can be swapped without changing the arrangement shape.
It won't change the sense of this value and the context in which we use it.
It is proposed to change it to The line bundles are swapped at the support.

Rationale

Several attempts to document line arrangements appeared in OSM tagging, sometimes merging attachments and arrangements, or specific topological situations with arrangements and so on.
This proposal intends to provide a more robust approach on this particular topic, without using tower:type=* or more particular tagging restricted to power=*.

Values are inspired from IEC 60050 norm, particularly from its 466-05 section for overhead power lines.
This proposal is first of all intended for power lines, but this tagging could easily be used with any other kind of line.

Need to document arrangements

Arrangements are both visible and important design constraints for some modern systems involving lines, energized or not.
It is part of knowledge OSM contributors can gather at large scale.
Availability of more and more precise data, coming from computer vision or lidar measurements will enable us to get such knowledge more easily. OSM could provide a proper tagging model in this constant progress movement.

Such knowledge will enable to get a more precise measure of line's size and width. Particularly for paragliding or free flying activities, aerial lines' dimensions will matter.
In a nutshell, it is useful for 3D modeling, safety measures when approaching lines and computer aided maintenance for power lines operators.
Some operators lack this knowledge and seek to improve their datasets by sharing what they already got and calling contributors on OSM.

What is a line bundle?

It actually depends on the line itself.

For power lines, we consider individual conductors (a group of one or several wires of the same phase in alternative current or the same pole in direct current) as a bundle. See cables=*.
In usual 3 phases lines of alternative current continental grids, you will get 3 bundles.

For telecommunication lines, each individual cable (a group of one or several copper wires or fibre assembled around a rigid core and a protective coating) is a bundle.

Both aerial and underground

Like line_management=*, it is useful to combine ability to describe both aerial arrangements and underground cross sections.
Precise arrangements solves the same kind of problems whether on overhead lines or underground cables. For instance capacity and insulation between conductors of power lines/cables.

Only map when you are knowledgeable about underground infrastructures: mappers can survey during construction works or get public documentation suitable with OSM license and guidelines.

Why on supports nodes only?

We could use line_arrangement=* on lines sections themselves, to describe how a given section is arranged.
It's true that most lines will be arranged following a single pattern and only sections where arrangement is changing won't be able to get a line_arrangement=* value.

As this could lead to massive cluttering of lines, encouraging mappers to cut them along arrangements are changing, isn't a so good solution.
Then, it's preferable to only encourage using line_arrangement=* on nodes as it doesn't encourage to create or delete geometries but only completing existing ones.

How different from design=*?

Documenting arrangements could lead to similarities with design=* used in combination with power supports.
It's true both arrangements and tower designs are linked but not equivalent.

Designs are mostly specific to countries or regions, depending on local constraints like engineering, materials availability, environment and weather. Several designs can lead to the same arrangement.
line_arrangement=* is intended to provide a common and objective way of describing many specific situations around the world.

A single design can actually support several arrangements, depending on particular conditions. For instance, H-frame or portal towers can independently support horizontal or triangular circuits with the exact same design (visually, but mechanically probably different).
Then line_arrangement=* could provide the right distinguishable knowledge.

By the way, some designs imply one single arrangement and those could be reviewed by each country and imply the corresponding line_arrangement=* value.
This can't be done globally and should be done once this proposal reviewed, so we won't change design=* values for now.

Tagging

Picture	Key/Value	Description
	line_arrangement=horizontal	IEC 466-05-02: Bundles of the line are arranged strictly horizontally on their support
	line_arrangement=semi_horizontal	IEC 466-05-03: Bundles of the line are arranged horizontally but center elements are slightly higher or lower, on their support. It covers at least two patterns: Left and right bundles are on a strict horizontal axis and middle elements slightly shift up or down. Bundles are along an oblique axis forming an angle of less than 45° with the horizontal. Any other possibility would lead to triangle
	line_arrangement=vertical	IEC 466-05-06: Bundles of the line are arranged strictly vertically on their support. Vertical arrangements are very often on one support side. Consider triangular when bundles are installed on either side of their support.
	line_arrangement=semi_vertical	IEC 466-05-07: Bundles of the line are arranged vertically but middle elements may be slightly shifted horizontally, on their support. It covers at least two patterns: Top and down bundles are on a strict vertical axis and middle elements slightly shift left or right. Bundles are along an oblique axis forming an angle of less than 45° with the vertical. Any other possibility would lead to triangle Vertical arrangements are very often on one support side. Consider triangular when bundles are installed on either side of their support.
	line_arrangement=square	Not part of IEC 60050. Bundles of the line are located on vertices of a square shape with as much horizontal elements than vertical ones.
	line_arrangement=triangular	IEC 466-05-04: Bundles of the line are located on vertices of a scalene triangle shape which base is not always horizontal.
	line_arrangement=delta	IEC 466-05-05: Bundles of the line are located on vertices of an isosceles triangle shape which base is not always horizontal. It could be also called trefoil sometimes, particularly underground.
	line_arrangement=unarranged	Bundles are not arranged following a particular pattern on their support. It's the default value.

Arrangements are depicted by the black dots.
Optional dots are drawn in grey and reflect supplementary bundles that don't change the pattern, in case of several lines attached to the support you look at.

Complex configurations

As already described for line_attachment=* and line_management=*, complex configurations can occur with several and different values for the same support.
It may be useful to propose combination to describe several arrangement on the same support too.

This proposal only focuses on simple values, with no combination, for supports only supporting one arrangement.
Another proposal will be necessary to consolidate Matrix_values notation and allow to use such complex values.
line_arrangement=* shouldn't contain composed values with ; and |. A sub-key like line_arrangement:matrix=* may be introduced later to use such combinations.

Power circuits perspective

Documenting arrangements on single circuit power lines is easy as bundles arrangements are directly translated to corresponding OSM value.

Power lines sharing the same supports need to be handled in regard of each of them.
For instance, 4 independent power lines sharing the same supports (12 bundles in 3-phases AC networks) can be arranged either as each circuit on a horizontal axis or the same 4 circuits can be arranged with a triangle shape which lead to different tagging actually.
As those arrangements usually do impact normal line operational status, it is important to look at each line independently, even when they share the same support.
The picture beside shows 4 lines cross-section on a single support and tries to show how circuits arrangement may change the tagging, despite having the same global appearance.

Mappers can identify power circuits by looking at places where they split apart toward different supports or on line_management=split supports, eventually in substations surroundings. Just follow the lines.
For instance to check this line: 121105300 121105300, you may have to go 1221112063 1221112063 there or 1356472776 1356472776 there.

Telecommunication lines perspective

Overhead telecommunications lines are usually unarranged unless specific environmental conditions could encourage to make telecom cables remain in a given position.
If so, we should look at the general shape to get the arrangement. It will usually be clear horizontal or vertical

Underground telecommunication pipes (hosting cables) are covered by the next chapter.

How to map underground

It is possible to use line_arrangement=* to describe arrangement of underground cables as well, if known as explained in rationale. Bundles of underground cables can be installed horizontally, vertically or even delta in similar shapes than overhead ones.
line_arrangement=* will be used the same way as line_management=*, on any node marking a particular line arrangement situation.

However, underground cables are buried in the ground and don't have any support. Usually on OSM, they have got nodes along their way points and turns.
Then, it is optional to use line_arrangement=* on any node and recommended on node where arrangement is changing along cables' path. Arrangements can change near of particular way points: when going through a bridge, a delta arranged cable can punctually be horizontally arranged to fit in the bridge for instance.
It is also recommended to use it on nodes joining two ways, if known.

The point is to make a reasonable usage of tagging, preventing cluttering of database. Such incomplete usage on some nodes require particular interpretation guidelines, see following chapter.

How to interpret

Proposed line_arrangement=* is intended to be used on particular points of lines, not on the lines themselves. Then, such a discreet usage will be accurate on a line's supports points but can be wrong or unknown right before and right after.
Consecutive instances of the same value of line_arrangement=* will mater to rebuild a continuous knowledge on a given line.

It's up to data consumers to manage transitions between two different arrangements on consecutive supports, if they need it.
They could also define the acceptable length threshold under which a section between two nodes with the same line_arrangement=* is suitable to solve with the same arrangement value any unqualified node located between.

Particular design constraints should be considered depending of the line we describe.
It's out of scope of this proposal to propose a comprehensive way to describe such constraints.

Edition management

Affected pages

• Create line_arrangement=* and add proposed values.
• Edit man_made=utility_pole and add combination with line_arrangement=*
• Edit power=tower and add combination with line_arrangement=*
• Edit power=pole and add combination with line_arrangement=*
• Edit power=insulator and add combination with line_arrangement=*
• Edit power=terminal and add combination with line_arrangement=*
• Edit line_management=transpose and change its description to The line bundles are swapped at the support.

External discussions

• French changeset discussion about some confusion between attachments and arrangements
• RFC announcement on OSM community forum

Examples

Overhead power

Photo	Location	Tagging	Note
	UK	power=tower line_attachment=suspension (optional line_management=straight) line_arrangement=semi_vertical	A classical power tower with straight two circuits line arranged in semi vertical pattern.
	Germany	power=tower line_attachment=anchor line_management=transpose line_arrangement=horizontal	A classical power conductor transposition with help of anchor attachment
	France	power=tower line_attachment=suspension line_management=straight line_arrangement=triangular	Two independent power systems are arranged in a triangular shape on this suspension tower. No vertical axis between bundles and two of them are horizontally aligned.
	France	power=tower line_attachment=anchor line_management=straight line_arrangement=semi_horizontal	Left and right bundle share the same horizontal axis while the central one is slightly raised: it's a semi-horizontal arrangement.
	France	power=insulator line_attachment=anchor line_management=transition line_arrangement=horizontal	The concrete portal supports an incoming line with horizontal arrangement.
	France	power=tower line_attachment=anchor line_management=split|transition line_arrangement=vertical location:transition=yes	Those towers supports two power circuits with vertical arrangement.
	France	power=tower line_attachment=suspension line_management=straight line_arrangement=semi_vertical	Two power circuits bundles are arranged along an oblique axis forming an angle of less than 45° with vertical, then it's semi horizontal arrangement.
	France	power=pole line_attachment=anchor line_management=split line_arrangement=horizontal location:transition=yes	The two lines ancor on this supports with a horizontal arrangement.
	UK	power=tower line_attachment=suspension line_management=straight line_arrangement=delta	A new kind of power tower in UK, with a special design of T-shape. Two 3 phases circuits are suspended on those supports. As the triangle formed by insulators for each circuits looks like isosceles, we use delta value here. As for the diamond transition/termination ones of the same design:

Underground power

Photo	Location	Tagging	Note
	New Zealand	On any node of this cable with that exact arrangement: line_arrangement=delta	Three underground power cables installed in black ducts, arranged in a delta shape. Orange ducts may be optical fibre or telecom wires. This example only covers the black ducts.
	Canada	On any node of these ducts, use the following: line_arrangement=square	The four ducts will host power cables and are maintained in place with a squared cross section.
	Germany	On any node of this cable with that exact arrangement: line_arrangement=vertical	Two power circuits running along a tunnel with vertical supports.

Misc

Photo	Location	Tagging	Note
	Spain	(currently missing tag for this horizontal bracket) line_attachment=anchor line_management=termination line_arrangement=horizontal	In case you were wondering: yes, it works for laundry lines.
	Nepal	power=pole Undefined attachment Undefined management line_arrangement=unarranged	We can barely conclude something about this particular pole. At least cables are not arranged.

Voting

Voting closed

Voting on this proposal has been closed.

It was approved with 11 votes for, 2 votes against and 3 abstentions.

Approved at 85% of approval rate

• I approve this proposal. --Nospam2005 (talk) 21:18, 21 June 2023 (UTC)
• I approve this proposal. --Ydel (talk) 22:04, 21 June 2023 (UTC)
• I approve this proposal. Thank you for the time spent on thinking of a great tagging scheme. --Babouche Verte (talk) 04:36, 22 June 2023 (UTC)
• I approve this proposal. --Overflorian (talk) 06:19, 22 June 2023 (UTC)
• I approve this proposal. --PanierAvide (talk) 06:29, 22 June 2023 (UTC)
• I approve this proposal. --Fanfouer (talk) 08:04, 22 June 2023 (UTC)
• I oppose this proposal. I think this is too much for OSM. I don't buy into the rationale - for flight safety, you would simply keep a large distance away from any power line, no matter how it has its lines bundled! I applaud the work that has gone into this detailed documentation and I appreciate that OSM is a geek project but mapping how individual lines in a bundle are arranged is not something we should expect from anybody. If powerline operators want to collect this data about their powerlines (because you say above that they often don't know it themselves and hope OSM might provide that info) then let them collect it but not in OSM, and let them not call on OSM volunteer time to do their work for them. I am also worried about your admission that it might be necessary to apply computer vision (i.e. automatic mapping) to even collect this information. I think you're right - data on this level of detail will only be collected at scale by people writing software to evaluate imagery. But OSM isn't a collection and distribution channel for auto-generated data. So, no, the electrical geekery in OSM has reached its limits IMHO and it's time to stop driving that further and further. --Woodpeck (talk) 08:39, 22 June 2023 (UTC)
• I have comments but abstain from voting on this proposal. Same as woodpeck, but I don't wanna be a spielverderber --chris66 (talk) 08:52, 22 June 2023
• I have comments but abstain from voting on this proposal. This is such niche tagging that I think it would have been better to have introduced a tagging schema more like power_line:arrangement=* rather than keep introducing new tags that aren't immediately clear what they relate to from their name only (what lines?). However, since other tags such as line_attachment=* (which could have been power_line:attachment=*) are already approved, I'm not going to vote against. --Casey boy (talk) 09:36, 22 June 2023 (UTC)

Guys, OSM tagging is more relevant than making mapping mandatory or clutter the database. If no data available, then don't map it. Fanfouer (talk) 10:35, 22 June 2023 (UTC)

• I approve this proposal. --AnakinNN (talk) 19:38, 22 June 2023 (UTC)
• I have comments but abstain from voting on this proposal. Same as Chris66 --501ghost (talk) 23:09, 30 June 2023 (UTC)
• I approve this proposal. I agree with the abstain votes that this might be too detailed - but we already have a lot of (too) detailed information and nobody is forced to go into detail this much. A namespace approach might have been better, but there are already several approved tags and this one fits in with them. There doesn't seem to be anything wrong with the proposal itself. --Mueschel (talk) 12:42, 2 July 2023 (UTC)
• I approve this proposal. --Technoeconature (talk) 16:42, 02 July 2023 (UTC)
• I approve this proposal. --Rouelibre (talk) 09:01, 3 July 2023 (UTC)
• I oppose this proposal. I think this is too much for OSM. Same as Chris66 --geozeisig (talk) 13:29, 3 July 2023 (UTC)
• I approve this proposal. --Lancelotance (talk) 14:35, 4 July 2023 (UTC)