Proposal:Utility facilities
| Utility facilities | |
|---|---|
| Proposal status: | Approved (active) |
| Proposed by: | fanfouer |
| Tagging: | utility=* |
| Applies to: |  
|
| Definition: | Consistently extend usage of utility=* to service/industrial landuses, buildings and cabinets |
| Statistics: |
|
| Draft started: | 2022-05-31 |
| RFC start: | 2022-08-12 |
| Vote start: | 2023-01-12 |
| Vote end: | 2023-01-26 |
Originally intended to be used with marker=*, utility=* has got a wider interest from mappers and it should now be reviewed in combination with landuse=*, building=* and man_made=street_cabinet.
Proposal
It is proposed to use utility=* in combination with landuse=industrial, building=service, building=industrial and man_made=street_cabinet to state in which essential infrastructure they are involved.
As a consequence, it is also proposed to deprecate and replace several values of street_cabinet=*, acting as specific duplicates of more general utility=*:
- street_cabinet=power with utility=power
- street_cabinet=telecom with utility=telecom
- street_cabinet=gas with utility=gas
- street_cabinet=street_lighting with utility=street_lighting
- street_cabinet=cable_tv with utility=television
- street_cabinet=water, street_cabinet=water_management with utility=water, according to the last definition (raw water, drinkable water).
- street_cabinet=water, street_cabinet=water_management with utility=sewerage, according to the last definition (used or polluted water).
As another consequence, it is also proposed to deprecate and replace values of industrial=*, acting as specific duplicates of more general utility=*:
- industrial=gas with utility=gas
It's currently not proposed to deprecate street_cabinet=* nor industrial=* globally, as other values don't correspond to proper utilities and will remain used.
It is not proposed to change anything regarding industrial=oil despite interest during the RFC. Tagging oil production and refinement facility will remain in industrial=* for now.
Rationale
utility=* key sounds to be an efficient way to link a large diversity of features to essential infrastructures, to begin with marker=* or man_made=utility_pole.
We can now make several specific similar concepts converge into this unified framework.
Keys like street_cabinet=* or industrial=* has got a similar meaning. They were introduced prior utility=* with a less elaborated tagging knowledge in mind.
Replacing the first by the more general last will not bring any additional information. It is useful to make different OSM data converge towards the same tagging model.
It will finally ease consumers' life, particularly renders and reinforce common tagging relevancy, while the two practices currently got an equivalent usage level around the world.
Proposed evolution of tagging is summarized in this table:
Some cells are left grey since some combinations are currently unusual, but not impossible.
Utility scope
However, not all industrial facilities, street cabinets/service buildings related to technical activities are linked to utilities.
Following activities aren't tied to utilities and are then out of the scope of this proposal:
- Public transportation (including railway)
- Traffic management and measurement (for the last, use monitoring:traffic=yes)
- Postal services
Oil production and refinement has been studied to be included in this utility=* proposal but further thinking is required. We should discuss on this particular point a bit more, particularly on industrial=oil Talk page.
Preserved street_cabinet=* values should remain unmodified on features and we may then use corresponding amenity=* or more specific tagging.
This proposal won't define any new tagging for that.
This proposal doesn't change the way utility=* is used in combination with features it combines to.
utility=* will still expect one single value for the main purpose of the facility, despite we address larger perimeters.
For instance, despite a wastewater plant needs power equipment and chemical to run, it should get utility=sewerage on its surrounding perimeter.
How do I find it?
Local signage, documentation or even knowledge can help to find the right value.
It is sometimes attached to the operator responsible to run the given facility you found.
For instance, if you find a blind cabinet in Japan with Tepco signage on it, you can use utility=power with high confidence level.
Industrial landuse
Some facilities are large enough to be contained in a wide perimeter landuse=industrial.
It currently doesn't exist a consistent way to state some of those industrial facilities are part of wider utility network.
Furthermore, industrial=* is mostly used to define the nature of such facilities, like refineries, works, warehouses.
It doesn't provide knowledge about what is processed (see substance=*) nor the actual activity. Replacing values like gas will free contributors from such inconsistencies.
Using utility=* when necessary will bring such knowledge to the whole perimeter at once.
This proposal only covers industrial landuses. It is not proposed to use utility=* on amenity=fuel neither on commercial offices.
Industrial/service buildings
Service/industrial buildings currently don't have a particular key to state in which utility they are involved.
This knowledge is as relevant as street cabinets and this proposal is an opportunity to have a common tagging standard for that.
Adding such a key to buildings allows to get a corresponding global surface reserved for each utility activities.
Usual risks mitigation and activities splits lead to dedicated buildings for one activity, which eases their description on OSM.
This proposal only covers service/industrial buildings that actually are part of networks/infrastructures. It is not proposed to use utility=* on commercial or head offices.
Street cabinets
utility=* is now used similarly to corresponding values street_cabinet=*, with same magnitude order.
This knowledge is useful and need to be preserved when replacing particular tagging practices with the more common one.
It doesn't sound necessary to introduce street_cabinet=utility and we may encourage to remove existing street_cabinet=* value when corresponding utility=* is available.
Tagging
man_made=street_cabinet, building=service, building=industrial and landuse=industrial tagging aren't changed, neither their affinity.
Regarding street cabinets, as of this proposal, unless street_cabinet=* refinement afterwards, utility=* replaces values of street_cabinet=*.
Edition management
Affected pages
Several pages are planned to be affected by the review of this proposal:
- Create and deprecate street_cabinet=power
- Create and deprecate street_cabinet=telecom
- Create and deprecate street_cabinet=gas
- Create and deprecate street_cabinet=cable_tv
- Create and deprecate street_cabinet=water
- Create and deprecate street_cabinet=water_management
- Create and deprecate street_cabinet=street_lighting
- Edit and deprecate industrial=gas
- Edit man_made=street_cabinet, add combination with utility=*
- Edit building=service, add combination with utility=*
- Edit building=industrial, add combination with utility=*
- Edit landuse=industrial, add combination with utility=*
- Edit utility=* and add combination with landuse=industrial, man_made=street_cabinet, building=service and building=industrial.
Tagging to be replaced
| Obsolete tag | Usage | Used for? | New tag(s) to use |
|---|---|---|---|
| street_cabinet=power | 51 752 on 2022-11-15 | The cabinet hosts power equipment | utility=power |
| street_cabinet=telecom | 29 301 on 2022-11-15 | The cabinet hosts telecommunication equipment | utility=telecom |
| street_cabinet=street_lighting | 1 369 on 2022-11-15 | The cabinet hosts street lighting equipment | utility=street_lighting |
| street_cabinet=gas | 1 401 on 2022-11-15 | The cabinet hosts gas equipment | utility=gas |
| street_cabinet=cable_tv | 888 on 2022-11-15 | The cabinet hosts cable television equipment | utility=television |
| street_cabinet=communications | 592 on 2022-11-15 | The cabinet hosts telecommunication equipment | utility=telecom |
| street_cabinet=water_management | 223 on 2022-11-15 | The cabinet hosts raw water or drinkable water measurement or control equipment | utility=water |
| street_cabinet=water_management | 223 on 2022-11-15 | The cabinet hosts polluted water measurement or control equipment | utility=sewerage |
| street_cabinet=broadband | 149 on 2022-11-15 | The cabinet hosts telecommunication equipment | utility=telecom |
| street_cabinet=water | 175 on 2022-11-15 | The cabinet hosts raw water or drinkable water piping | utility=water |
| street_cabinet=water | 175 on 2022-11-15 | The cabinet hosts polluted water piping | utility=sewerage |
| industrial=gas | 9 459 on 2022-11-15 | An industrial facility processing gas | utility=gas |
Approx 100 000 occurrences need to be replaced
How to proceed
- Wiki will be changed during the post-vote cleanup phase and it's not an option.
- What to do for deprecation to lead to old key not being created anymore? Validation rules in editors as to encourage mappers to replace the old key by the new one.
- Support for new key should be lobbied for: Editors presets and second part of validation rules. As mostly proposed replacements aren't rendered on osm-carto, it won't be necessary to make any modification.
- What needs to be done with existing usage of old tags: Here, nothing. Mappers will carefully replace then when they found them. No need to propose an automated edit.
External discussions
- RFC announcement on Tagging mailing-list
- RFC continues on OSM Community forum
- RFC continues on Tagging mailing-list
- Industry vs utility discussion on industrial=* Talk.
Examples
Industrial landuses
| Photo | Location | Tagging | Note |
|---|---|---|---|
 |
France |
landuse=industrial
|
Large wastewater plants are industrial facilities, using chemicals substances and mechanical machinery to process sewerage and prevent pollution. It can be combined with utility=sewerage. |
Street cabinets
| Photo | Location | Tagging | Note |
|---|---|---|---|
 |
UK |
man_made=street_cabinet
|
The cabinet seen on the front hosts a DSLAM device to provide higher bitrates to households. It is described with utility=telecom |
 |
France |
man_made=street_cabinet
|
A gas delivery substation self contained in a street cabinet. It is involved in utility=gas activities. |
 |
France |
man_made=street_cabinet
|
A power substation intended to feed households with low voltage electricity. It is involved in utility=power activities. |
Service buildings
| Photo | Location | Tagging | Note |
|---|---|---|---|
 |
Unknown |
building=service
|
A dedicated building hosting a power substation and then involved in power utility. |
 |
Austria | Service building in a wider pipeline substation, involved in gas transmission through pipelines. | |
 |
Germany | Water valve room in front of a covered reservoir deserves to be involved in water utility. | |
 |
France |
building=service
|
A dedicated building hosting telecommunication exchange is involved in telecom utility. |
Voting
Voting on this proposal has been closed.
It was approved with 19 votes for, 4 votes against and 1 abstention.
Approved at 83% of approval rate
I approve this proposal. I deeply approve this rationalisation of tags. Thanks for the proposition. Will you do the PR in ID and JOSM ? Babouche Verte (talk) 03:15, 12 January 2023 (UTC)
- Yes sir, editors presets and validation rules will be improved during post vote cleanup Fanfouer (talk) 11:34, 12 January 2023 (UTC)
I have comments but abstain from voting on this proposal. I don't see a solution for Talk:Proposed_features/Utility_facilities#deprecate_old_street_cabinet_values separately showing the activity supported and equipment inside when they are different. There is no added benefit to "approving" the use of utility=* on man_made=street_cabinet, and "deprecating" street_cabinet=* without a replacement for this situation is undesirable. On top of that, the debate on utility=* concerning industrial is not clearly settled, and it has wider implications for landuse=industrial, industrial=*, etc. ---Kovposch
- Step by step. As answered what is contained into something isn't the point of street_cabinet=* as the same issue raises for buildings. This voting doesn't prevent to work on this later Fanfouer (talk) 09:28, 12 January 2023 (UTC)
- I approve this proposal. -- Something B (talk) 11:09, 12 January 2023 (UTC)
- I approve this proposal. --Ydel (talk) 11:32, 12 January 2023 (UTC)
- I approve this proposal. --Benoitdd (talk) 13:35, 12 January 2023 (UTC)
- I approve this proposal. --Rjw62 (talk) 13:37, 12 January 2023 (UTC)
- I approve this proposal. Good idea to use a single key-value pair for all OSM objects related to a particular utility. --JeroenvanderGun (talk) 15:53, 12 January 2023 (UTC)
- I approve this proposal. --Fanfouer (talk) 16:06, 12 January 2023 (UTC)
I oppose this proposal. The present vs future tagging table is flawed: the landuse column shows values that are rarely used. Industrial=water (500 uses) is in practice tagged as man_made=water_works (30k+ uses). "sewerage" land use exists and is in practice tagged as man_made=wastewater_plant (75k uses). I also don't like the ideat to put (drinking) water and sewage in one category ("water"). More Generally, I don't like proposals of "wiki gardening" that result in mappers being confronted with lists of "deprecation" warnings every time they upload changesets that regard completely unrelated features. Maybe I am atypical as I often map road features of interest to cyclists, which means that I am downloading a lot of data that re unrelated to my actual editing interest, and I notice a steady increase of deprecation warnings. 100k changes is a lot of work. --voschix (talk) 20:36, 12 January 2023 (UTC)
- Hello Volker, did you read my answer on @tagging? This proposal won't make water and sewerage in one family water. Could you check it please? Fanfouer (talk) 22:15, 12 January 2023 (UTC)
- Did you read too fast the proposal? Even the first lines of the proposal propose to get rid of the ambiguous "street_cabinet=water, street_cabinet=water_management" by adding of utility=water or utility=sewerage. --Nospam2005 (talk) 10:29, 14 January 2023 (UTC)
- I approve this proposal. --Nospam2005 (talk) 10:29, 14 January 2023 (UTC)
- I approve this proposal. I think the approach of standardizing tagging is good and I support the proposal for infrastructures. But I have a problem using utitlity on area definitions. I know industrial is a big construction site and doesn't clearly define what it is meant to describe as it includes both areas and facilities. At least for the areas, utility is no substitute for industrial for me and I would stick with landuse=industrial + industrial=* there. This has good logic to me (like landuse=residential + residential=*). I see it similarly with building=service + service=*. --Chris2map (talk) 12:55, 14 January 2023 (UTC)
- This proposal won't prevent to go on with landuse=industrial + industrial=*. It only converts industrial=gas to utility=gas as it refers to utility and will actually reinforce any other suitable industrial=* value to be used with it. Fanfouer (talk) 13:01, 14 January 2023 (UTC)
- That didn't become clear to me when reading the text and the discussion. I have now seen the sentence #Tagging "...landuse=industrial tagging aren't changed". If so, I support the proposal and change my vote to yes. Perhaps this will offer the opportunity to get a little more clarity in industrial, since a few values that do not fit area definitions can be described using utility. --Chris2map (talk) 13:22, 14 January 2023 (UTC)
- I approve this proposal. --Renecha (talk) 23:08, 19 January 2023 (UTC)
- I approve this proposal. Thanks for this well documented and discussed proposal. While it adds some duplication for e.g. power=*, I get the point that it is useful to have all utilities under a common key and room for cases where the actual function is unknown. --Skyper (talk) 13:31, 20 January 2023 (UTC)
- I approve this proposal. --AnakinNN (talk) 15:50, 20 January 2023 (UTC)
- I oppose this proposal. There is no way I will be subjected to osmosis alerts to correct deprecated tags. As long as a mechanical edition is not planned, I will always vote against this kind of proposal. I do not serve the radicals of the attribute model, sorry François --Deuzeffe (talk) 07:19, 21 January 2023 (UTC)
- I approve this proposal. --Kjon (talk) 12:46, 21 January 2023 (UTC)
- I approve this proposal. utility perfectly fills a gap that I have been regularly confronted with as well. Naming/structure seem to work out well to me. However, I disagree with the unnecessary of street_cabinet=utility. I would recommend using it, otherwise there will be an, in my opinion, unfortunate gap beside non-utility values like street_cabinet=postal_service or street_cabinet=traffic_control. --Supaplex030 (talk) 15:10, 21 January 2023 (UTC)
- I oppose this proposal. This proposal changes very popular tagging without a transition plan that includes contacting existing data consumers and defined time frames for transitioning (and it doesn't actually make clear who will do that work). It further does not make a case why the minuscule gains outweigh the disruption and work it will cause. SimonPoole (talk) 12:02, 22 January 2023 (UTC)
- I approve this proposal. --EneaSuper (talk) 12:21, 22 January 2023 (UTC)
- I oppose this proposal. not convinced this is sooo necessary for well-used tags, introduced not that long ago.--JB (talk) 13:57, 22 January 2023 (UTC)
- I approve this proposal. --Nw520 (talk) 10:18, 23 January 2023 (UTC)
- I approve this proposal. --Reino Baptista (talk) 10:53, 25 January 2023 (UTC)
- I approve this proposal. despite some reservations with deprecating industrial=gas (which may be eventually repurposed for industrial gas facilities such as Linde/BASF/Messer). Duja (talk) 13:19, 25 January 2023 (UTC)
- I approve this proposal. --Gendy54 (talk) 18:32, 26 January 2023 (UTC)