Proposal:Service supplies proposal
| Service supplies proposal | |
|---|---|
| Proposal status: | Proposed (under way) |
| Proposed by: | fanfouer |
| Tagging: | line_management=service_supply
|
| Applies to: | 
|
| Definition: | Provide a dedicated value for nodes on which utility service supplies connects to main lines for any network, different from branches |
| Statistics: |
|
| Draft started: | 2025-03-14 |
| RFC start: | 2025-08-15 |
Utility networks like electricity, water or even gas often goes along streets to allow individual consumers to connect them with service drop or service lateral towards their homes or companies.
Service lines connecting individual consumers may be considered as particular branch lines starting from main lines towards households.
However and despite they can be part of the public network, they are often designed for a single consumer and are way smaller than other lines.
This proposal intends to define a dedicated line_management=* value to simplify mapping of utility distribution networks, first of all for power, without connecting each house to main lines (without preventing anyone who wants to do so).
This proposal is intended for any utility network and it can be took for power networks as to ease understanding.
Proposal
It is proposed to add following tagging:
line_management=service_supplyvalue to be used on nodes at which consumers lines connect to main utility lines. First of all for power and more broadly for water, gas... (waiting for a formal proposal forline_management=*to support pipelines). It will have the same combination capabilities asline_management=branch.occupancy=*/occupancy:[utility]=*to count how many premises are supplied by the distribution line on a given point (i.e counting the visible drops without mapping them)
It is also proposed to improve the line_management=branch definition to exclude service supplies: Any connection where a side line, except service supplies, coming from a different direction connects to a continuous main line on a support or on a junction box underground.
Rationale
A service supply is intended to feed an individual household from distribution network nearby. It is defined as per 601-02-12 IEC60050 definition.
It differs from utility main lines that are designed to feed a group of customers or facilities with a more important capacity.
If this proposal got adopted, no one will be forced to map service supplies nor count them on poles. This proposal intends to refine our current practice and bring new method useful for anyone who want to describe such things.
A particular branch point
line_management=branch will now be dedicated to points on which several main/secondary lines connects.
Service supply lines are particular branch lines and often smallest assets of larger utility networks.
When overhead, they are called service drops and are barely seen from aerial imagery of even from streets.
When underground, they are usually called service laterals (North American at least) and may be seen when connecting to a pole nearby to reach overhead public network (mostly for power or telecom but sometimes for gas too).
Many of those supplies can be seen in residential streets and mappers may be interested to only describe points on which they connect on the main lines without going through the hassle of mapping each of them.
As line_management=service_supply is intended to abstract too detailed mapping, mappers won't be prompted to connect three or more lines on those points.
On the contrary, line_management=branch will require a T-point at least for sake of mapping consistency of main lines.
Furthermore, mappers shouldn't be able to end a main line with branch instead of service_supply and should be warned when such a situation occurs.
Such service points may already got particular tagging depending on the utility. See telecom=distribution_point for telecommunications for instance.
Prevalence with existing values
Service supplies may connect on particular nodes already covered with existing line_management=* values. We should define how it will change current practice when such situation arrise.
This section deals with actual connection of one or more service supplies on a given line that also transitions or branches on a node. It is not about combination of several values about independent lines we discuss about downside. Prevalence is the only solution as combining values is dedicated to situation with independent lines on the same support.
This proposal considers following situations to occur:
- service_supply against branch of two main lines: mappers should use
branch+ appropriateoccupancy:*=* - service_supply against straight or termination: mappers should use
service_supply - service_supply against transition of the main line: mappers should keep
transition+ appropriateoccupancy:*=*. - service_supply against transition of the service supply: mappers should use
service_supply+location:transition=yes
service_supply against split would not fit in this section. Advanced usage table below would recommend straight|service_supply.
Properly ending rural mains
In rural areas, overhead power main lines or underground water mains may stop by isolated households, finally supplying a single consumer.
As those drops may not be seen during surveys or from aerial imagery, proposed line_management=service_supply may allow to properly end the main lines and state that it explicitly stops by the consumer drop without mapping the service line itself.
Currently, mappers that don't want to map service drops can't properly terminate the main lines seen on ground.
It's not possible to use line_management=termination because it's not a proper termination where the main line would actually stop without any service drop.
Proposed line_management=service_supply has got a double advantage to distinguish service supplies form branch ones and provide a convenient manner to end distribution main lines that stop by consumers drops.
Isolated poles intended for service drops from underground network
Even in urban areas, some utility poles may be designed to connect homes with aerial service drops whereas the public network had been previously buried underground. Such properties certainly lack underground ducts in their private vicinity and aerial lines remain required even after the public network went underground in the street.
It can currently lead to isolated power poles without any line connected and a warning in quality assurance tools.
Proposed line_management=service_supply will allow to distinguish such poles and prevent any irrelevant encouragement to map power lines by them.
Permanent occupancy versus capacity
OpenStreetMap use to map available capacity=* and relates to what's available at a given feature (parking lots, households, ...). It may apply to many public utilities connections but won't help to map actually existing connections.
We indeed need another concept which refers to the actual occupancy on points with higher capacity. For instance a telecom distribution point may allow to connect up do 7 land lines (capacity) but will be found with only 3 land lines connected (occupancy) at a given time.
We could have proposed a dedicated key for utilities in this proposal, nevertheless it was more consistent to propose occupancy=* / occupancy:*=* that matches existing capacity=*.
Occupancy can be volatile and related to important churn. As OpenStreetMap only focuses on permanent information, there will be no point to use occupancy=* to map parking lots availability.
It becomes applicable for things that don't change often, like service drops installation. Changes in this field is often related to more important works, building construction for instance. Then collected information on ground about them remain valuable for months or even years.
Defining such a key and introducing a practice to count service drops will save us from mapping individual drops for the sake of counting them. It is still possible to map service drops for different views, if the local community can bare this effort and maintain the data.
Tagging
This proposal won't change current line_management=* usage.
This key will still be used on nodes only.
Use line_management=service_supply or combine it as necessary depending on the situation encountered at each point a service supply taps any network main line.
Service supply lines themselves will be mapped just like any other line (mostly with power=minor_line or man_made=pipeline).
You can additionally count them with help of occupancy:[utility]=*.
Advanced usage
line_management=service_supply is proposed with same combination capabilities as line_management=branch:
| Value | straight |
branch |
service_supply |
split |
transpose |
termination |
transition
|
|---|---|---|---|---|---|---|---|
straight
|
straight
|
|
|
split
|
|
|
split/transition or simpler splitif several transitions |
branch
|
|
branch
|
|
|
|
|
|
service_supply
|
|
|
service_supply
|
|
|
|
|
split
|
split
|
|
|
split
|
|
|
|
transpose
|
|
|
|
|
transpose
|
|
|
termination
|
|
|
|
|
|
termination
|
|
transition
|
split/transition or simpler splitif several transitions |
|
|
|
|
|
transition
|
Situational sketch
Prior to deal with real life example, it would be useful to summary some possible situations in the following sketch.
We assume the power lines are always on top of any other utility, particularly telecommunications.
| Sketch node | Tagging | Comments | Proposals notes |
|---|---|---|---|
| A | power=pole
|
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 this proposal |
| B | power=pole
|
A power pole supporting both power and telecommunication wires. The main power line is branching and one household is supplied with underground service lateral.
|
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
|
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
|
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
|
Both power and telecom main lines are going straight at this pole. It also serves for three power overhead service supplies.
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 service_supply and split for telecommunication, so the resulting value is (service_supply) pipe (split). |
| F | power=pole
|
A power pole where main line branches without any service supply. | Outside of the proposal's scope |
| G | power=pole
|
A power pole supporting a straight main power line without any service supply. | Outside of the proposal's scope |
| H | -- | 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, despite suitable.
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 too 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.
Change management
No existing tags should be replaced by the current proposal review.
Affected pages
- Create
line_management=service_supplypage - Edit
line_management=*page to add service_supply value - Edit
line_management=branchto refine the definition as proposed - Edit
telecom=distribution_pointto add mention ofline_management=service_supplyandoccupancy:[utility]=*to count actual supplies
External discussions
Examples
Power
| Photo | Location | Tagging | Note |
|---|---|---|---|
 |
France | Public power distribution network comes through the black overhead cable and stops at the pole in front of the house. Then, a short but visible service supply line connects the building.
| |
 |
France |
|
Public power distribution network comes through the black overhead cable and stops at the pole between two buildings. Then, two service supply lines connect them.
|
 |
Japan |
|
Service drops can connect to main lines without needing a support. This examples refers to suspended boxes which look like to connect 2 independent service drops each.
|
Voting
Vote has not been started yet.