Key:line_management

line_management

Description

Describes particular topologies of lines around their supports or significant points along their path

Group: infrastructure

Used on these elements

Documented values: 8

Useful combination

Status: approved

More details at taginfo

Tools for this tag

taginfo · AD · AT · BE · BR · BY · CH · CH² · CN · CZ · DE · DACH · DK · FI · FR · GB · GR · HU · IE (N+S) · IN · IR · IT · LI · LU · JP · KP · KR · NL · NO · PL · PT · RU · ES · AR · MX · CO · BO · CL · EC · PY · PE · UY · VE · TW · UA · US · VN

Line management refers to particular topologies of overhead lines or underground cables. It often applies to utilities networks with power or telecom lines.
The values below are intended for power networks, but their use may be extended to other activities, if suitable.

Tagging

It was proposed to use a new line_management=* key to free tower:type=* and pole:type=* from defining how lines are arranged. This would allow us to keep tower:type=* to define tower shapes and to extend line management concepts to other types of support such as poles, portals or even terminal anchors. Current available tagging describes these situations globally without any specific terminology regarding power nor telecom. This key is mainly applicable to utility networks and it can easily be extended, with more specific terms, to other fields as well.

Simple supports, with no particular line management focus, should not be tagged with the line_management=* key or default straight.

This table is auto-generated. See Template:Taglist for a documentation on it.

Advanced usage

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`	`service_supply`	`split`	`transpose`	`termination`	`transition`
`straight`	`straight`			`split`			split/transition or simpler `split` if several transitions
`branch`		`branch`
`service_supply`			`service_supply`
`split`	`split`			`split`
`transpose`					`transpose`
`termination`						`termination`
`transition`	split/transition or simpler `split` if several transitions						`transition`

Situational sketches

Concrete use cases summarizing many individual possibilities are helpful to match with real situation you may face.
It is not mandatory to use this tag on any particular support node. Use this key only when a particular topology you found requires to be clarified.

Power grids

	Termination pole `power=pole` `line_attachment=anchor` `line_management=termination` `line_arrangement=horizontal`
	Branch pole `power=pole` `line_attachment=anchor` `line_management=branch` `line_arrangement=semi_vertical` Y connection then it's a branch.
	Split pole `power=pole` `line_attachment=anchor` `line_management=split` `line_arrangement=semi_vertical`
	Branch pole `power=pole` `line_attachment=(pin)\|(anchor)` `line_management=branch` No arrangement for now as several are mixed on this support
	Cross pole `power=pole` `line_attachment=(pin)\|(anchor)` `line_management=cross` No arrangement for now as several are mixed on this support
	Transposition tower `power=tower` `line_attachment=anchor` `line_management=transpose` `line_arrangement=horizontal`

Distribution utilities

Distribution toward particular consumers or in residential areas involves smaller assets that may look messy or difficult to follow since we barely see them.
OpenStreetMap tagging can help to map only what matters and reduce the hassle of describing every connection to each house.

Sketch node	Tagging	Comments	Review notes
A	`power=pole` `line_management=service_supply` `occupancy=2`	The main power line stops on this power pole, supplies two households, so the power line is properly terminated by `service_supply`.	One of the main situations covered by `line_management=service_supply`
B	`power=pole` `line_management=(branch)\|(service_supply)` `location:transition=yes` `telecom=distribution_point` `power:occupancy=1` `telecom:occupancy=1`	A power pole supporting both power and telecommunication wires. The main power line is branching and one household is supplied with underground service lateral. Telecommunication operator had also installed a distribution point to supply one household overhead as well.	Power level mixes a branch and a service lateral and according to prevalence from rationale chapter, branch wins. Telecommunication has only one service drop from a straight line for service_supply applies. The resulting value is a combination of two levels: (branch) pipe (service_supply).
C	`man_made=utility_pole` `utility=telecom` `line_management=service_supply` `telecom=distribution_point` `occupancy=2`	Telecommunication operator had installed a distribution point to supply two households from this pole. No power is supported here. We assume this pole may be smaller than power ones and is intended to support only telecommunication lines, so `man_made=utility_pole` applies here.
D	`power=pole` `line_management=service_supply` `location:transition=yes` `telecom=distribution_point` `power:occupancy=1` `telecom:occupancy=4`	Both power and telecom main lines are going straight at this pole. It also serves for several service supplies, one underground power and four overhead for telecommunications. Even if two telecommunication service drops aren't going straight to the houses they serve, they are count there as they connect to main line on this pole.	Both levels, power and telecommunication, support straight main lines with one or several service supplies, so resulting value is service_supply.
E	`power=pole` `line_management=(transition)\|(split)`	Power main transition to ground and telecom main go straight at this pole. The two telecommunication service drops only pass by this pole toward supplied households.	Power is on top and telecommunication below. Value for power is clearly transition and split for telecommunication, so the resulting value is (transition) pipe (split).
F	`man_made=street_cabinet` `utility=power` `line_management=service_supply` `occupancy=3`	The power main line stops by this cabinet used to connect subscribers. Its shape may be casual in many countries (sometimes with fixed `capacity=*` when known) and indicates it serves as a power connection box for households.	Mappers may not always know it serves 3 households, since they are served from underground. In some cases, the box may be open or damaged enough to take a picture. `occupancy=*` should be used responsibly, always with verifiability principle in mind to add values when possible.
G	`power=pole` `line_management=branch`	A power pole where main line branches without any service supply.	Outside of the proposal's scope
H	`power=pole` `line_management=straight`	A power pole supporting a straight main power line without any service supply.	Outside of the proposal's scope
I	--	An underground pipe branch where two house holds are supplied from the water wain with possibly meters installed for the two connections. It is installed inside an underground box which isn't covered by the current scope.	It should be `line_management=service_supply` but currently unsupported, as `line_management=*` hasn't been reviewed for pipelines yet.

Furthermore this table, the sketch also shows underground water main lines where line_management=branch is suitable for two nodes on which they branch and line_management=service_supply for all of 5 nodes where service laterals connect to main lines. However, line_management=* waits for a formal proposal to extend its usage on pipelines, despite suitable it shouldn't be used yet on them.

We also see that tagging on nodes won't completely define how service supplies are arranged nor which households are served. Optional service drops and laterals should be drawn to get this knowledge.
Some complex situations on most used poles won't be completely solved for now as connected lines aren't related to a particular level on the pole. This would require core changes to OSM relational data model to support tags involving ways and nodes.

Key:line_management

Contents

Tagging