Proposal talk:Utility facilities

landuse=utility

Resolved: landuse=industrial has been added in the proposal with utility

I also like the utility concept in combination with landuse=*, because I have occasionally faced the problem that a suitable category for utility areas/sites is missing in the landuse key. Maybe it is worth adding this to the proposal. According to TagInfo, landuse=utility is currently used ~200 times. --Supaplex030 (talk) 09:19, 21 August 2022 (UTC)

That's a good point thank you !

As it's currently not proposed to introduce building=utility and street_cabinet=utility, landuse=utility won't be necessary either to combine landuse=industrial with corresponding utility=* value when applicable, will you?

639202457 639202457 this water works facility is a good example of what could be landuse=industrial + utility=water instead of using utility=water on each building Fanfouer (talk) 16:13, 21 August 2022 (UTC)

I remember a motorway maintenance site where I used landuse=utility (and where we had a little debate in our local community and found this tag very suitable). It's hard for me to classify that as "industrial" landuse... But if there is a broader community consensus on this, I could also live well with the variant landuse=industrial + utility=*... --Supaplex030 (talk) 20:06, 21 August 2022 (UTC)

Why not landuse=industrial (or something about depots) or landuse=highway (as in landuse=railway)? Roads are not a "utility". Kovposch (talk) 07:05, 22 August 2022 (UTC)

You are right - I looked again at the definitions of utility and industrial in both English and German usage, where there seem to be small differences. In the English sense, "industrial" fits better. utility=* should only be used for public energy and water providers. --Supaplex030 (talk) 08:04, 22 August 2022 (UTC)

power=* is recognized as landuse=industrial. --- Kovposch (talk) 07:05, 22 August 2022 (UTC)

I agree that highway infrastructure actually rely on utility but isn't a dedicated one.

As the discussion goes,would it be good to combine landuse=industrial with utility=* when applicable? Fanfouer (talk) 18:05, 22 August 2022 (UTC)

I would say: absolutely yes. --Supaplex030 (talk) 08:19, 24 August 2022 (UTC)

More diverse utility=* values

I want to propose to take this opportunity to introduce more diverse or detailed utility=* values.
As a professional I am active in the sector and often miss more detailed tagging to distinguish between different utility networks. Both located on private as public land.
Some examples:

• utility=gas lacks defining different gas networks.
  • natural_gas should allow diversification from the more general used utility=gas
  • nitrogen mostly only for industrial use;
  • oxygen for industrial use and health facilities;
  • CO or carbon monoxide for industrial use;
  • hydrogen, for industrial use but recently extended to public and private use (fuel stations, public buildings, residential)
  • CO2 or carbon_dioxide for industrial use.
• utility=telecom lacks defining different telecom networks.
  • fiber_optic, different usage might be combined in one fiber cable, like telecommunication, traffic monitoring, utility or pipeline monitoring etc.... Traffic monitoring, measuring equipment should be obeserved as a utility network as the signals are more and more transfered through or combined in fiber optic infrastructure. Broadband seems a misuse to me, as it describes a capacity of a telecom connection but does not implicate fiber infrastructure. Many countries have broadband connections f.i. over coaxial cable infrastructure.
  • coaxial, might also have different use on the same cable like voice, data, video...
  • etc...
• utility=sewerage lacks defining seperated sewerage networks:
  • rainwater;
  • raw_sewerage;
  • gray_water, which is treated raw sewerage. Not potable water but can be used for irrigation, direct surface water disposal, cooling water...
• utility=steam is completely missing
• utility=cathodic_protection is completely missing

Above list is surely not complete and I didn't check if some of the values are already in use.
I thought about adding additional diversitifcation tags, like f.i. gas=*, or telecom=* but many of them are already in use for other purposes.
A seperate issue comes when different utilities are combined in f.i. one street cabinet. Can tag them as ; seperated values ?
--- Bert Araali

Hi @Bert Araali: and thank you for this suggestion.

However, utility=* define macro activities or departments/branches and shouldn't be used for more precise qualification allowed by different keys that should be used on precise equipment and not on containing landuse or buildings.

gas can be completed with substance=* when applicable on different features

telecom will take advantage of telecom:medium=* to define on which physical layer the network relies.

By the way, look at the first lines of utility=* page: it shouldn't be confused with substance=*. utility=steam should be moved to utility=heating + substance=steam.

Cathodic protection is a particular equipment of a pipeline, not an utility activity. Such protections are used for gas, oil or even water depending on use case.

We need to separate concepts on different keys and we certainly can't define everything in the utility=* space Fanfouer (talk) 08:17, 23 August 2022 (UTC)

Waste and wastewater were discussed in Talk:Key:utility#Duplicate_values. Neither cathodic protection, nor utility=loudspeaker elsewhere, are "utility". They can be found in all utilities. : --- Kovposch (talk) 15:00, 24 August 2022 (UTC)

deprecate old street_cabinet values

Resolved: Old street_cabinet values are deprecated, but not the whole street_cabinet key as we keep remaining values in it

Under the street_cabinet section you says: "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"

I would say to take a stronger position and deprecate the old street_cabinet values. Otherwise you keep having both. --Cartographer10 (talk) 17:30, 23 August 2022 (UTC)

That seems legit, for values.

I'll update the proposal shortly, thank you! Fanfouer (talk) 22:38, 23 August 2022 (UTC)

Personally, I feel it is a bit unfortunate to tag some street_cabinets with street_cabinet=* (e.g. postal service) and others with utility=*. I think in my area I would additionally use street_cabinet=utility, even if you explicitly do not intend this in the proposal. Maybe that's just my personal understanding of order and consistent classification... --Supaplex030 (talk) 08:33, 24 August 2022 (UTC)

One distinction I didn't get with utility=* is whether it means the facility or function, especially for electricity and communication, since they are everywhere. Is a switchboard, transformer, backup generator / battery / fuel cell, or any electrical equipment for other utilities a utility=power? Similarly for communications, for infrastructure monitoring, and traffic control & surveillance. So not sure all "hosts power equipment" and "hosts telecommunication equipment" interpreted from street_cabinet=power and street_cabinet=communications are equivalent to utility=power and utility=telecom here. Users may see electrical or communication equipment, but don't know what they are for, or how to distinguish them. It should be clarified utility=* is for the utility service provided, not the exact equipment used.
Eg I understand some building=service and perhaps man_made=street_cabinet in my place don't control or monitor/count traffic themselves directly, only transmitting & receiving data/info/commands. I won't use utility=telecom (nor even street_cabinet=traffic_*) for them,
Therefore I have hoped street_cabinet=* should have its definition adjusted, not deprecated.
--- Kovposch (talk) 10:26, 24 August 2022 (UTC)

That's an interesting discussion and could lead to adjust both proposal and current documentation.

utility=* value depends on the scope you are observing. Despite power and telecom are obvious, according to France's practices (could be different elsewhere), 639202457 639202457 would get utility=water and 1035160560 1035160560 inside should get utility=power as it's the power supply of the facility.

A street cabinet intended to control traffic signals shouldn't get utility=power despite there is power in it. Just like an man_made=utility_pole operated by telecommunication operator and installed mainly for telecommunication purposes will get utility=telecom despite it sometimes supports power conductors operated by another company.

Currently, street_cabinet=* can't be deprecated, I see no valid solution to replace street_cabinet=postal_service for instance.

I could have proposed brand new values to precise exact shape of the cabinet, from small boxes supported on walls or poles to larger cubicles with doors and light inside. Without solution to replace existing values that's not possible however valuable it could be Fanfouer (talk) 14:02, 24 August 2022 (UTC)

Well, that's a more unique and technical example for myself. Let's take the more common case of a railway. Should utility=power be it added to every building=service, landuse=railway, and man_made=street_cabinet (or equivalent, or maybe for tram and LRT) hosting power=* equipment? When it's fully inside railway operations, out of utility operator's control. That's a question I had too. More edge case could be chemicals for water treatment (although usually produced on-site), cooling water, hydro-electric powering water, etc.
I was only thinking the list of street_cabinet=* being deprecated here.
--- Kovposch (talk) 14:56, 24 August 2022 (UTC)

Regarding railways, no, I wouldn't add utility=power to every building or cabinet even if they host power equipment. I could at least on substations, those which are the limit of power utility network and internal railway systems. Same for local transportation systems.

By the way, I wonder which tags are suitable for a typical cabinet hosting switches to isolate two sections of overhead contact line sections for a city tramway system. Such cabinets on public power network are described as utility=power + power=substation, that wouldn't be suitable for railway or transportation ones, even in the street.

I indeed plan to deprecate the street_cabinet=* values currently, unless I find suitable solution for more values to propose a new definition regarding form factors. Fanfouer (talk) 22:56, 24 August 2022 (UTC)

That's why I wanted to keep the street_cabinet=* val for equipment inside. Use utility=* for the activity. --- Kovposch (talk) 10:16, 26 August 2022 (UTC)

We'll have the same issue for buildings, it's not specific to street cabinets. I'm looking for a common solution for them Fanfouer (talk) 16:56, 26 August 2022 (UTC)

It is not necessary or helpful to change industrial or street_cabinet

The current tags are fine: street_cabinet=* works well for defining the kind of man_made=street_cabinet and industrial=* is used to specify the kind of industrial facility under landuse=industrial. It will not be helpful to change some of the values of street_cabinet=* and industrial=* to use the key utility=* while other values are still under the prior keys. I believe it is easier for mappers if each sub-type of a feature can be specified by using one additional key. Adding street_cabinet=* to man_made=street_cabinet is the standard way to do this; mappers will find it intuitive, while utility=* will not be immediately obvious. If all type of street cabinet could be described with utility this would be a minor complaint, but in this case different types will need to use a different key, which will only add to confusion. I oppose this proposal and will vote against it.--Jeisenbe (talk) 19:51, 20 November 2022 (UTC)

Can you explain the benefit to have industrial=oil in the middle of industrial=refinery and industrial=well_cluster please?

By the way, and as mentioned in rationale, moving from street_cabinet=* to utility=* is only intended to unify the way to provide the same information. street_cabinet=* has been proposed earlier with less tagging logic in mind. Why should we have street_cabinet=* for cabinets and currently no key for buildings? Fanfouer (talk) 20:00, 20 November 2022 (UTC)

I agree with @Jeisenbe: here - esp. moving just some of the street_cabinet=* to utility=* will create more confusion than it will solve. It should not be done at all (or if there are big advantages that it should be done, which has not been not shown IMHO, then it should be done for all values, not just some of them) --mnalis (talk) 06:44, 21 November 2022 (UTC)

However it's how things actually are in real world. We have many building=*, some of them can get utility=* some don't, just like man_made=street_cabinet which aren't all utility cabinets. I'm not responsible of that. It's more confusing to have separate street_cabinet=power, building=power and utility=power than utility=power only.

Not all values of street_cabinet=* refer to utility=*. Why should all street_cabinet=* values remain grouped if our current experience shows they should be better organized?

I'm the author of proposal which introduced man_made=street_cabinet and street_cabinet=*. We hadn't the same experience back in 2014 and such improvements have to be made now after several years of mapping projects and OpenStreetMap improvements. utility=* has been introduced in 2019, we didn't had it before. It was less possible to get a better design in 2014. Fanfouer (talk) 14:02, 21 November 2022 (UTC)

Replacing something that is used hundreds of thousands of times requires enormous effort!

Proposal just states mater of factly:

   Approx 160 000 occurrences need to be replaced 

Who and how exactly would be doing that, and in what timeline?

See https://community.openstreetmap.org/t/changing-rfc-time-for-proposals-including-deprecation/5661/2 for description of just the most basic things that needs to be done, and evaluate any possible gains against huge amount of effort and inconvenience. Please specify for each of the 4 bullet points mentioned there how exactly they are proposed to be dealt with. --mnalis (talk) 20:13, 20 November 2022 (UTC)

Well, as both street_cabinet=* and utility=* are used at same extent, current consumers should take them both and won't be bothered by the time needed to replace the first by the last.

I don't feel any necessity to organize mass edit for such, mappers will be invited to review existing tagging and change it if appropriate.

We're dealing with millions of features remaining to be tagged around the world. 160k objects is just nothing, sorry. Fanfouer (talk) 20:47, 20 November 2022 (UTC)

That does not answer the 4 points mentioned there, really. Should I copy them as 4 separate issues to make it easier to answer separately? Also, I am totally not approving of logic "there is 30 times more unmapped object with tag X, so all currently mapped X are irrelevant / just nothing" which I am reading from your comment. Is there misunderstanding? Somebody invested a lot of effort into creating those 160k objects, dismissing it as "just nothing" does not seem to show appropriate respect all that work done by our fellow mappers. --mnalis (talk) 06:54, 21 November 2022 (UTC)

There is a misunderstanding here. I didn't said that original mapping is nothing, it's obviously valuable and useful work we improve every day. I only relate quantities and usage. It's a problem to stuck tagging in establishment with 160k objects while we look for millions remaining to be mapped. Mappers hadn't done anything wrong nor useless by using original tagging. However we have to move on under the circumstances detailed in Rationale chapter.

1. changing the wiki is easiest: Yes, it's not a question, nor an option.
2. 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
3. support for new key should be lobbied for: Editors presets and second part of validation rules. Renders maintainers very often discard updates without further usage of new keys, so I don't spend my time there any more (and street_cabinet=* isn't rendered).
4. 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. Fanfouer (talk) 14:12, 21 November 2022 (UTC)

Oil & gas and utilities

In my neck of woods, I have tagged numerous industrial=oil and industrial=gas for petrochemical extraction and production facilities, such as [1] (and none related with transport or distribution of those). There is no w:Public utility involved whatsoever. So, unless you expand the proposal to cover (and not merely deprecate) tagging of extraction vs. production facilities, it's a non-starter. Duja (talk) 21:57, 20 November 2022 (UTC)

I see no problem to cover extraction and production in utility=*. Water catchments, well pumping stations, drinking water works are production infrastructures suitable for utility=water for instance.

No need to extend utility=*, its description already states They provide useful energy or fluids from production sites to consuming places with according pipes or cables..

The question is, how consistent industrial=oil is with industrial=refinery? Fanfouer (talk) 22:10, 20 November 2022 (UTC)

There are 3 problems with this.

1. Oil is not always an end use. It can be converted to utility=power and utility=water.
2. There is less association with it as a public utility.
3. There is industry=*, product=*, and others that might be used to replace industrial=*. Criticisms detailed in Talk:Key:industrial.

Similar to what I pointed out, what do you do with an electricity or heating company's oil and gas infrastructure? Are they utility=power and utility=heating, or utility=oil and utility=gas? What about their cooling water, and are hydroelectric and pumped storage's water transferring infrastructure utility=water?
industrial=* should be considered comprehensively in a separate proposal. Kovposch (talk) 05:56, 21 November 2022 (UTC)

Answer on the 3 points:

1. Utility is not necessary an end use. Power grid usually feed water processing facilities, just like oil could be used in further processing.
2. utility=* isn't focused on public utilities. operator:type=* is here to help
3. I don't contest there are many other key that could be used to solve consistency and de-normalization issues. industry=* is wider than utility=*.

The point isn't to tag every component with utility=* here. Penstocks, valves, dams are part of a power=plant relation that could get utility=power. Fanfouer (talk) 13:50, 21 November 2022 (UTC)

2. That is not about public utilities. A public utility can be public, private, PPP, or whatever corporate form.
This is the same question I have for street_cabinet=*. The equipment and utility activity are not always the same.
---
--- Kovposch (talk) 07:35, 22 November 2022 (UTC)

I don't properly get the point you intend to make and how I can take care of it in the proposal. I'd be in favour of including old&gas in utility industry as they mostly feed another processes, just like power or water infrastructures. This is understood from technical perspective. They are many different economical contexts we don't address in the utility=* key. Look at 452322511 452322511, utility=gas + industrial=compression_station would be way more valuable.

The point on equipment vs activity, as upside: a power supply cabinet inside a railway yard or oil refinery isn't supposed to get street_cabinet=power nor utility=power here. In this proposal, such cabinets are part of a larger facility perimeter which will get (or not, because actually not an utility) the proper utility=* value.

Describing equipment inside the cabinet shouldn't be a matter of street_cabinet=* as most kind of equipment isn't found in cabinets only. It should be a matter of the equipment tagging itself, out of the scope of this proposal. Fanfouer (talk) 08:38, 22 November 2022 (UTC)