Key:line_arrangement

From OpenStreetMap Wiki
Jump to navigation Jump to search
Public-images-osm logo.svg line_arrangement
Line arrangement illustration.png
Description
Consistently describe how lines bundles are arranged (vertical, horizontal, delta...) around a given support or way point Edit this description in the wiki page. Edit this description in the data item.
Group: infrastructure
Used on these elements
may be used on nodesshould not be used on waysshould not be used on areasshould not be used on relations (except multipolygon relations)
Documented values: 8
Useful combination
Status: approvedPage for proposal

Line arrangement is about how cables or bundles are geometrically located around their supports.
Depending on environmental, operational and distances, overhead or underground lines may be designed in a way that ensure their proper operation, sometimes insulation.
Definitions, details and examples are given on each value pages.

Arrangements are useful information for power, telecom or even cable transportation systems. It is intended to deal with standard geometrical configurations for several activities instead of defining a specific framework for each.
Values are took from IEC 60050 norm, for power lines at first and widely applicable on many other lines.
line_attachment=*, line_management=* and line_arrangement=* are also intended to free tower:type=* and pole:type=* from defining how lines connect to supports.

How to map

On every line support nodes, tower, poles, or particular underground way points, add line_arrangement=* with the corresponding value to the situation you intend to describe.

Tagging

Here is the list of considered values for this key:

LOADING TAG LIST... (If you do not see this tag list, you need to enable JavaScript)
This table is auto-generated. See Template:Taglist for a documentation on it.

Advanced knowledge

Which lines are covered

This documentation covers lines in a very wide sense.
This key is not only intended for power lines and can be used on telecommunication, cable transportation systems or even clothes lines if you wish.

A line is composed of wires or cables, energized or not, intended to move electricity, data or goods from one place to another.

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.

Advanced practice

Complex configurations

Actual split with anchor attachment

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.

Currently, line_arrangement=* should be used with simple values only, with no combination, for supports only supporting one arrangement.
Further work 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

Line arrangement horiz vs triangle.png

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: way 121105300, you may have to go node 1221112063 there or node 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

Line arrangement underground pipes.png

It is possible to use line_arrangement=* to describe arrangement of underground cables as well, if known according to verifiability principle. 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

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 documentation to propose a comprehensive way to describe such constraints.

See also