Proposal talk:Power utility office

Handling of existing tag (current and future use)?

How is existing and continuing office=energy_supplier to be handled? I.e. do you propose just to modify the wiki to say its deprecated, but all current tools will continue to use it (until someone opens separate ticket for them to change behaviour)? Or do you plan to research what tools create them, and open (and followup on) the tickets needed to get editors to actually stop using old tag? (and also open tickets for data consumers to handle both tags, until old one is gone completely)

Also, apart from deprecation, do you also have a plan what to handle already existing tags (and if so, how)?

Because, if not, the likely result is that we'd then have two different tags for mostly the same thing, which might increase confusion the instead of lowering it - e.g. https://xkcd.com/927/ --mnalis (talk) 20:14, 18 November 2022 (UTC)

iD, Vespucci and JOSM currently have a preset for it, which can be easily changed. The name suggestion index has operator data for such companies which covers a few hundred objects. I'm not aware of any data consumers of this specific data. If you are talking about OSM powered application, they can be handled with a ticker for each one in their issues tracker. Dimitar155 (talk) 20:27, 18 November 2022 (UTC)

@Dimitar155: Correct, that is what I'm talking about. Someone would need to do the research to determine which apps/websites which are using OSM data use that tag specifically, then open tickets for each of them outlining what would need to be done for transition, and then (preferably) followup that they actually implement it (many lower-priority tickets simply never get solved unless someone keeps bugging about it - unfortunate sideeffect of more tickets than manpower). That requires some work, and I wonder if the proponent is willing to do that work / take that issue into account when doing cost/benefit analyses. --mnalis (talk) 20:39, 18 November 2022 (UTC)

That's the point of having https://taginfo.openstreetmap.org/projects. Of course there are apps/websites which are not listed there but there is not much that can be done, except asking them to get themselves listed.Dimitar155 (talk) 20:45, 18 November 2022 (UTC)

Yeah, the point of https://taginfo.openstreetmap.org/projects is to reduce that research effort (but only if the data consumer is listed there!) Still, it is not comprehensive, and it is not trivial to add support (especially where list of tags supported changes on the daily basis; one would have to code and change their workflow to support Taginfo projects, or do massive manual categorizing). For example, neither of quite popular data consumers I happen to use (OsmAnd and OrganicMaps) seems to show in the TagInfo list of projects. Also, specialized tags like this one are likely to be featured on specialized smaller websites, which may not have support for Taginfo projects either. To make long story short, yes, one should definitely use Taginfo projects list as a part of their research, but not as an only source. Also, even when list of affected products is known with certainty, there is still work to write appropriate tickets for each of the products. --mnalis (talk) 21:07, 18 November 2022 (UTC)

If one can't list his project there, he should at least keep an eye on https://wiki.openstreetmap.org/wiki/Changelog every once in a while. Also, one should notice when the data on their app/site starts missing and investigate what happened. Dimitar155 (talk) 21:12, 18 November 2022 (UTC)

@Dimitar155: It doesn't work that way. The person who is proposing to introduce the breaking change is the one who has to invest themselves in cleaning up the breakage they will cause. The stance of "lets break things for no particularly good reason, and rely that most other people will sooner or later notice that we've broken it, and will have to invest their own time to fix it" is not really acceptable in my book.The more breakage one proposes, the more effort they need to be ready to put in to fix that. That's why I proposed to use method which will not cause damage, thus lessening the work for you and everyone else: Talk:Proposed_features/Power_utility_office#Use_sub-key_instead --mnalis (talk) 23:05, 18 November 2022 (UTC)

You do realise that we are talking about 15 app and editors in the worst case (iD, JOSM, Vespucci, Potlatch (assuming it has preset for it), OsmAnd, Organic Maps and Qwant maps (which is not problematic since they show all office=* POIs), Every Door and possibly other smaller navigation/editing apps)? Dimitar155 (talk) 06:38, 19 November 2022 (UTC)

Retailer tagging

What is the proposed tagging for an energy retailer? If the current tag is deprecated and replaced, what happens to retailers? Diacritic (talk) 20:19, 18 November 2022 (UTC)

office=power_utility is the proposed tagging for an energy retailer. Dimitar155 (talk) 20:40, 18 November 2022 (UTC)

Are the new and old tag exactly the same?

- If it is intended that they are exactly the same, perhaps it would better to clarify existing wiki than to introduce new, competing tag.

- If they are not exactly the same, then the exact differences should be outlined, and if old tag is deprecated, alternative

For example, in Croatia, energy supplier may be either of providing electrical power to households/industry, or it might be providing natural gas, or it might be doing both. if office=power_utility is only about electrical power, and office=energy_supplier is not to be used (because it is deprecated as unclear), then there obviously needs to be additional tag for non-electrical energy sources before old tag is deprecated. --mnalis (talk) 20:27, 18 November 2022 (UTC)

The wiki page is quite unclear on that topic but judging on the fact that it mentions "energy", I think that it shouldn't have been used for other energy providers in the first place. Do you have any suggestions for non-electrical energy sources? Dimitar155 (talk) 20:38, 18 November 2022 (UTC)

What? I'm fully confused know. You say "it mentions "energy" => it shouldn't have been used for other energy"? What? Why shouldn't the word "energy" be used for talking about Energy? That is exactly what it should be used for, IMHO. (or is there some automated translation to/from English issue?) There exist different types of energy, and electrical energy is just one of them (the other, at last equally popular, is chemical energy; cf. Russian war and world-wide energy crisis stemming from it). As for my suggestion for tagging different energy suppliers, see Talk:Proposed_features/Power_utility_office#Use_sub-key_instead below. Also see suggestions in Tagging ML thread. --mnalis (talk) 22:10, 18 November 2022 (UTC)

Personally I associate energy with electrical energy unless other type is specified (like mechanical or thermal energy). Dimitar155 (talk) 06:10, 19 November 2022 (UTC)

Use sub-key instead

I prefer the wider scope of office=energy_supplier. If think further distinction is needed (i.e. name=*, description=* etc are not enough), I'd prefer to keep existing office=energy_supplier (which neatly avoids all the hassle of needing to handle existing and future uses of that "old" tag), and introduce new sub-tag energy_supplier=* with sub-categorizations you think are useful (energy_supplier=natural_gas. energy_supplier=electrical_power, energy_supplier=electrical_infrastructure, etc). Then people can add that details if they know them (and leave existing simply as more coarse versions until someone adds extra details to them)

Update: it seems there already exist utility=* which might be good enough as subtag, at least to distinguish different energy sources.

--mnalis (talk) 20:29, 18 November 2022 (UTC)

The utility key already has quite a few usages and possible conflicts with other tags (substance and usage for example). I would like to not add more complexity around it. Probably office=gas_utility would be a better alternative. For power distribution, there can be another value of office (or office=company + company=something). Dimitar155 (talk) 21:05, 18 November 2022 (UTC)

I do find such narrow tags problematic. In Croatia, for example, many energy companies provide both gas and electricity, They can be tagged with current schema with office=energy_supplier, as they are energy supplier (with two different types of energy offered: electrical and chemical). With your proposal, one would have to tag them as either office=gas_utility or office=power_utility either of which would be problematic and lacking. If we're going to make changes, I'd much prefer even wider (more inclusive) tag like "public_utility", as suggested in tagging ML --mnalis (talk) 22:20, 18 November 2022 (UTC)

I don't see what "possible conflicts" and "more complexity" there are. A long list of office=*_utility is more complex. office=utility + utility=gas;power solves 2 problems at the same time. --- Kovposch (talk) 06:03, 19 November 2022 (UTC)

We would have to deprecate office=water_utiltiy as well in order to have some consistency. Dimitar155 (talk) 06:08, 19 November 2022 (UTC)

To me, utility=*, substance=* and usage=* are complementary. They won't replace nor overlap each other. For instance substance=steam is suitable for both utility=chemical and utility=heating and utility=heating can make use of substance=hot_water or substance=steam.

By the way, I admit utility=* was thought for industrial facilities. See this ongoing proposal to get more information about its extent. Fanfouer (talk) 17:39, 20 November 2022 (UTC)