Proposal:Lines management
| Lines_management | |
|---|---|
| Proposal status: | Approved (active) |
| Proposed by: | Fanfouer |
| Tagging: | line_management=* |
| Applies to: | |
| Definition: | Qualify power supports where lines branch, transpose, split or cross with versatile terminology |
| Statistics: | |
| Draft started: | 2019-10-15 |
| RFC start: | 2019-10-26 |
| Vote start: | 2020-05-23 |
| Vote end: | 2020-06-06 |
This proposal is the second one about the tower:type=* key cleaning.
You may be interested to read more about it
Proposal
It is proposed to introduce the key line_management=* to be used with power=line, power=minor_line and power=cable nodes only to describe particular topologies around their supports or significant points along their path. This includes nodes which are tagged power=tower and power=pole.
Proposed values are straight, branch, split, transpose, cross, transition and termination which correspond to visible and practical situations on the ground (see examples below). Defaults to straight.
These values are applicable for overground and overhead power lines, as well as underground power cables.
Chosen terminology won't prevent tags usage on different features later, but that is not within the scope of this proposal.
This proposal also discourages (deprecates) the use of several values of tower:type=* and pole:type=* in combination with any power support:
- branch
- termination
- transposing
- crossing
- branch:type=* will be deprecated as well
Rationale
Line management is about the how lines are arranged on a given support. They can branch, cross, split or their wires can transpose.
Here are some definitions in use in power domain, useful to define some values of this proposal
- Branch line (601-02-10) : A side line connected to a main one to feed some consumers hard to reach with main network
- Transposition (466-05-10) : A change in the conductor/bundles configuration of a line. The transposition may be intended to preserve grounding or interference conditions (power/telecom lines)
- Termination (461-10-01) : End part of a line intended to properly ensure safety and insulation on a point of connection on a dedicated support.
OSM currently describes the management of power lines mainly with multi-purpose key tower:type=*. The same key is used to make the difference between a castle and a telecommunication towers based on their structure and material. This is inconsistent and less usable for mappers.
This information is useful for telecom wires too. Then it's more appropriate to deal with standard cable management terms and share those concepts without specialised terminology for each domain.
It is proposed to use a new line_management=* key to free tower:type=* and pole:type=* from defining how lines are arranged. This would allows us to keep tower:type=* to define towers shape and to extend line management concepts to other kind of supports like poles, portals or even terminal anchors. Current available tagging describes those situations globally without any specific terminology regarding power nor telecom. This proposal is mainly usable for utilities networks and this work could easily be extended with more specific terms or be used for other fields of knowledge also with further proposals.
Proposed key doesn't imply you will always be able to determine a management pattern. Proposed values are intended for clear situations where mappers will be able to define how lines are arranged. This won't be suitable for messy supports with dozen of cables coming from everywhere.
Among other things, current tower:type=crossing is used to describe individual towers designed to make lines crossing large obstacles like rivers. As it's not a matter of topology nor proper line management, it's proposed to move it through height=* and design=* which give a better description for such infrastructure. Note that no new design=* are proposed to match those situations.
Simple supports with no particular line management situation aren't supposed to get line_management=* key.
Concrete benefits
- Share equivalent concepts between many fields of knowledge (power, telco, cable transport / towers, poles, masts, terminal and portals) and provide to mappers a common set of terms matching what they will actually see on the field.
- Ability to describe on the same feature how lines are arranged and simultaneously how they are attached (with line_attachment=*) without get stuck on domain specific terminology. This isn't possible with single tower:type=* which would take anchor or branch but not both simultaneously.
- Split according values to a dedicated key and free tower:type=*, pole:type=* with less related values. Prevent the definition of same kind values to :type keys.
Tagging
Use line_management=* on nodes only, corresponding to power supports or junction points of underground cables and eventually remove any use of tower:type=*
Values shoud reflect following situations:
| Picture | Key/Value | Incompatible on the same support level with | Description |
|---|---|---|---|
| line_management=straight | straight, transition, split, cross | Default and optional value for any line going straight on a given support or point. Direction of line can change at the support.
| |
| line_management=branch | branch, cross | Any Y connection.
| |
| line_management=split | split, straight, cross | Two or more distinct lines split apart towards different paths. Incoming circuits have to come from the same origin and diverge.
| |
| line_management=transpose | transpose, cross | The conductor bundles' arrangement changes at the support | |
| line_management=termination | termination, cross | A termination implies one or more lines are anchored on a given support with no connection between them.
A support with location:transition=yes, connecting an underground cable to one of the incoming overhead lines is not a termination, see transition, branch or split instead. | |
| line_management=transition | straight, transition, cross | A transition is a location change, often when overhead line connects to underground cables.
This value is only suitable for overhead lines that stop. For underground cables connecting to a continuous overhead line, see branch. This value should be used in combination with existing location:transition=yes. | |
| line_management=cross | Can't be combined. Incompatible with all values | This value indicates there is no connection between two or more lines coming from different directions sharing a given support at different levels. It avoids the use of tags like
|
Transition supports aren't terminations
It is assumed that a support connecting an underground cable to an overhead line isn't a proper termination for sake of consistency with split, branch and transition definitions.
Simple transition supports should only use the line_management=transition tag and see line_attachment=anchor and location:transition=* to complete tagging.
Use cases
Level composition matrix
As many situations exists in reality, it can be useful to combine (line_management=<left value>|<right value>) 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 independent 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.
| Value | straight | branch | split | transpose | termination | transition |
|---|---|---|---|---|---|---|
| straight | straight | split | split/transition or simpler split if several transitions | |||
| branch | branch | |||||
| split | split | split | ||||
| transpose | transpose | |||||
| termination | termination | |||||
| transition | split/transition or simpler split if several transitions |
transition |
Real life chart
Finally, let's illustrate this proposal with a concrete use case summarizing many individual possibilities.
Further thinking is required to address complex situations, as line management can mix several configurations on different tower levels.
Once a little more work will be done on Matrix_values, proposed values for line_management=* could be used together to better reflect situations occurring on the same tower/pole support node.
Furthermore, it is not mandatory to use this tag on any particular support node. Use this key only when you are sure that the value is suitable for the situation you found.
You'll find below a chart illustrating what you should see on ground and how to use corresponding line management values.
| Termination pole power=pole line_attachment=anchor line_management=termination | |
| Branch pole power=pole line_attachment=anchor line_management=branch Y connection then it's a branch. | |
| Split pole power=pole line_attachment=anchor line_management=split | |
| Branch pole power=pole line_attachment=(pin)|(anchor) line_management=branch | |
| Cross pole power=pole line_attachment=(pin)|(anchor) line_management=cross | |
| Transposition tower power=tower line_attachment=anchor line_management=transpose |
Edition management
Affected pages
- Create line_management=* and add proposed values.
- Edit tower:type=* and remove branch, split, transpose, cross and termination related to power=tower association
- Edit power=terminal to mention line_management=termination or line_management=transition.
- Edit power=insulator to mention appropriate line_management=* values.
- Edit power=portal to mention appropriate line_management=* values.
- Edit power=pole and change pole:type according values for line_management=*.
- Edit pole:type=* and warn about possible mistakes with line_management=*
Values to be replaced
| Obsolete tag | Usage | Used for ? | New tag(s) to use |
|---|---|---|---|
| tower:type=branch ( + branch:type=tap) | 550 on 2020-01-18 | A side anchored line connect to the main one | line_management=branch |
| tower:type=branch ( + branch:type=split) | 1656 on 2020-01-18 | Two or more independent circuits continue in different directions | line_management=split |
| tower:type=branch ( + branch:type=cross) | 204 on 2020-01-18 | Two or more independent circuits share a common support without connection | line_management=cross |
| tower:type=branch ( + branch:type=loop) | 108 on 2020-01-18 | Split point of two unconnected lines feeding a given substation towards two different directions | line_management=split |
| tower:type=termination | 5064 on 2020-01-18 | The line ends on a dedicated support | line_management=termination |
| tower:type=transposing | 545 on 2020-01-18 | Conductors or bundles configuration or position changes | line_management=transpose |
| tower:type=crossing | 1412 on 2020-01-18 | A support is significantly higher and stronger to allow a line to cross an obstacle like rivers | height=* + design=* |
| pole:type=branch ( + branch:type=tap) | 915 on 2020-01-18 | A side anchored line connects to the main one | line_management=branch |
| pole:type=branch ( + branch:type=split) | 323 on 2020-01-18 | Two or more independent circuits continue in different directions | line_management=split |
| pole:type=branch ( + branch:type=cross) | 52 on 2020-01-18 | Two or more independent circuits share a common support without connection | line_management=cross |
| pole:type=branch ( + branch:type=loop) | 4 on 2020-01-18 | Split point of two unconnected lines feeding a given substation towards two different directions | line_management=split |
| pole:type=termination | 1374 on 2020-01-18 | The line ends on a dedicated support | line_management=termination |
A whole total of 12 200 objects have to be edited, which doesn't sound so important regarding the >10 million power towers in OSM and the remaining potential to be mapped worldwide
Examples
| Photo | Location | Tagging | Note |
|---|---|---|---|
| UK |
power=tower
|
A classical power tower with straight two circuits line. | |
| Germany |
power=tower
|
A classical power conductor transposition with help of anchor attachment | |
| UK | Two independent power systems split at the tower | ||
| Germany | Four splits on two separate towers. If you look at connection, you'll see there is no Y connection and it's only independent power systems that change of direction | ||
| France | A side line connects to the main one (the presence of hanging insulator in the red circle doesn't affect this line management situation) | ||
| France |
power=insulator
|
The concrete portal should be mapped as a way and the line should connect to it on a power=insulator node. A bay line (inside the substation) connects to the incoming line, it's a transition from the management point of view | |
| France |
power=tower
|
Two power circuits split on this tower with an underground transition | |
| France |
power=pole
|
A particular situation becoming common thank to networks burring : an old overhead switch anchor pole has been refurbished to split the original overhead line in two sections and connect them to underground cables toward an indoor switching busbar. It's a split since two lines coming for a same origin go different ways. | |
| France |
power=pole
|
A medium voltage power line terminates on a concrete pole to connect to a distribution transformer | |
| France |
power=pole
|
A medium voltage overhead power line connects to an underground power cable on a pole. It's a straight connection without situation like branch or split so it's a transition. | |
| Austria | A side cable, probably a private customer connection, connects to a main underground cable in a junction box.
| ||
| Missing free illustration. See this one 1693163670 1693163670 | France | Two different lines share a single tower here and cross their directions. It's an actual cross tower. | |
| UK |
- |
This is not a valid situation for line_management=cross. Lines have to share a common support without connection to be considered crossing. |
Voting
Voting on this proposal has been closed.
It was approved unanimously with 20 votes for.
- I approve this proposal. --EneaSuper (talk) 10:54, 31 May 2020 (UTC)
- I approve this proposal. --Eric B. (talk) 06:13, 23 May 2020 (UTC)
- I approve this proposal. --PanierAvide (talk) 06:54, 23 May 2020 (UTC)
- I approve this proposal. --CjMalone (talk) 07:59, 23 May 2020 (UTC)
- I approve this proposal. --Lmagreault (talk) 12:20, 23 May 2020 (UTC)
- I approve this proposal. --Nospam2005 (talk) 19:12, 23 May 2020 (UTC)
- I approve this proposal. --AlexModesto73 (talk) 20:27, 23 May 2020 (UTC)
- I approve this proposal. --Fanfouer (talk) 14:32, 24 May 2020 (UTC)
- I approve this proposal. --Dr Centerline (talk) 18:19, 24 May 2020 (UTC)
- 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)
- Discussion goes on Talk page Fanfouer (talk) 18:16, 25 May 2020 (UTC)
- I approve this proposal. --TOGA (talk) 11:22, 27 May 2020 (UTC)
- I approve this proposal. --Gileri (talk) 11:56, 28 May 2020 (UTC)
- I approve this proposal. --Renecha (talk) 20:46, 29 May 2020 (UTC)
- I approve this proposal. Crochet.david (talk) 11:46, 31 May 2020 (UTC)
- I approve this proposal. --Soldier Boy (talk) 17:25, 31 May 2020 (UTC)
- I approve this proposal. --Gendy54 (talk) 19:04, 31 May 2020 (UTC)
- I approve this proposal. --liotier (talk) 00:38, 1 June 2020 (UTC)
- I approve this proposal. --Riiga (talk) 10:52, 1 June 2020 (UTC)
- I approve this proposal. --VileGecko (talk) 13:34, 3 June 2020 (UTC)
- I approve this proposal. --hendrik-17(talk) 15:49, 4 June 2020 (UTC)
- I approve this proposal. --Sommerluk (talk) 07:20, 6 June 2020 (UTC)