Proposal talk:Substation functions

Main benefits of the proposal

@Fanfouer: I think that this proposal won't make it, because you are offering any improvement for the mapper.

IMHO it's questionable to enforce a single tagging scheme for things from two different worlds – electrical and pipeline infrastructure.--Svensson (talk) 21:42, 9 January 2019 (UTC)

Regarding some substations, we're currently puzzled to choose between substation=transmission and substation=converter because two fits. With help of new keys, it won't be unclear anymore. Mappers will be asked more clear questions dealing with hierarchy in one hand and functions on the other.

It's not the first proposal to introduce a common tagging scheme for similarities in pipelines and power. It continues the work began years ago. As mentioned, already two proposal has been written for substations tagging. Do you see any mistakes in what is proposed? Fanfouer (talk) 22:07, 9 January 2019 (UTC)

No, I don't see any mistakes in your previous proposals.

Have you some example where a substation really has both transmission and converter functions at the same time? My idea is that in most cases the substation could be splitted into two parts with distinct functions.--Svensson (talk) 06:53, 10 January 2019 (UTC)

According to IEC 601-01-09, transmission is not an actual function but a hierarchy level. Functions like Transformation, Switching or Conversion can be active in substation at any hierarchy level.

Have a look here for an example. Even if the substation can be split in two different parts (because of different operators), both will get substation=transmission and only one will have substation:conversion=yes. Conversion is a function operating in only few transmission substations. Fanfouer (talk) 18:55, 10 January 2019 (UTC)

Under Keys to be replaced you list the combination of distribution and conversion, do you have an example for that? At the moment I only know of HVDC converter stations and the DC ties in the US, both of which would certainly be considered transmission in your scheme. For now I have to agree with Svensson, that there seems to be no clear benefit.--TOGA (talk) 04:24, 23 January 2019 (UTC)

The key point is that current substation=* key mixes two orthogonal concepts: role/hierarchy in the network and some power management functions. The functions can run whatever the level or role of the substation. Examples shows that functions can be picked up by operators to build a substation matching their needs in a particular place even if default schemes usually apply.

As HVDC networks are pretty well in use worldwide, norms on LVDC distribution networks are currently in debate and involve power converters. See the abstract of this IEEE paper or this document about that topic. It's currently not possible to add a conversion substation to a distribution network since substation=converter implies it's a transmission node, which is not always true.

As a mapper and a substation data consumer, I see here incompatibilities between OSM and raising power data models which are currently under construction (see OpenMod for instance). This proposal ensure OSM data will be usable with less difficulties than now and mappers will be asked more clearly about substations. Fanfouer (talk) 23:15, 23 January 2019 (UTC)

Thanks for those links, definitely interesting, although it isn't really clear how far away real word usage is. Nevertheless you're right that we probably should plan ahead. That being said, we already tag the voltage levels of a substation, so wouldn't it be possible to get the distinction between HVDC/MVDC/LVDC that way? I certainly wouldn't hold the current description on substation=converter against it. The main function of the wiki is to document the tagging found in the database and we cannot tag what doesn't exist. I don't necessarily see a problem with rewording that sentence in the future.--TOGA (talk) 22:57, 25 January 2019 (UTC)

You're welcome. The voltage won't give you the purpose for which the network is built. Look at my chart, you have more items than only transmission or distribution. Voltage is not enough to get a proper knowledge, LVDC can serve in traction, industry or distribution.

Even we look forward to tag what currently exists or what is currently able to be mapped, the validity of tagging isn't based on the existance not the accessibility of data but on the consistency of the whole namespace. Since convertion/transformation/switching/... are orthogonal to transmission/distribution/industry/traction they shouldn't mix in the same key. This doesn't mean you will fill the whole matrix, but there is actually a matrix, not a single row of values, then several keys are needed. Fanfouer (talk) 00:36, 26 January 2019 (UTC)

To be honest I don't really get it. To me transmission/distribution etc. are also functions and even the descriptions in your proposal say so. For example under transmission substation it is stated that "a transmission substation is a substation whose main function is to...". Another example is the definition for a traction substation which reads "a substation, the main function of which is to supply a traction system". The current tagging scheme aims to tag just this main function to get a broad categorisation of substations. That doesn't mean that a substation cannot also perform other functions. The question then is if we need further taggging on substations. My opinion is that the current scheme with substation=*, voltage=* and frequency=* should be enough. In the end OSM is a geospatial database and if you need even more detailed information it should be no problem to get that by analysing the devices of a substation.--TOGA (talk) 03:19, 28 January 2019 (UTC)

That's exactly the problem I try to solve. The main function in the definitions you mentioned is actually a set of functions fulfilled by several components inside the substation.

Regarding substation=traction you're not able to determine if there is conversion or not because trains electrical systems can transmit AC or DC power. substation:conversion=yes will certainly help. frequency=* is not applicable to a substation because even in a conversion substation you'll find both AC and DC (and most of all this key is a device attribute, not intended for complex sites).

The proposal stands for hierarchy agnostic functions. With all due respect to previous and current contributors on this topic, it's really limiting (and semantically false) to stay with conversion=transmission or traction=no switching. It confuse both mappers and consumers. Fanfouer (talk) 22:05, 28 January 2019 (UTC)

Finally, OSM is not a geospatial database at all. It's a topological dataset built above a fully relational database. All the data can be converted into a geospatial schema with the help of osm2pgsql for instance. Nevertheless it's not possible to build any tagging model with the hypothesis we'll be able to complete information by looking for surrounded features (I use to believe in this, you'll certainly find some of my old contributions in favor of this but experience shows it's not feasible nor desirable). Fanfouer (talk) 22:19, 28 January 2019 (UTC)

Sorry for not being precise with the terminology, that's definitely not my special subject. That being said, it's still my impression that this should be possible and you also state something similar in this proposal under Special use cases:

There is no point to distinguish the renewable or intermittent property on the substation itself. Such information should be visible on the corresponding power=plant surrounding or involving the generation substation.

But I'll inquire about the possibilities and get back to you.--TOGA (talk) 22:32, 31 January 2019 (UTC)

No problem with precision, we'll have to explain terminology to not knowledgable mappers. Regarding renewables or intermittency, it's a plant property, not a substation one. It's not the point to propagate it to substation from the plant, it should stay on the plant only. Fanfouer (talk) 21:01, 1 February 2019 (UTC)

In the last week I looked at the capabilities of Overpass API and I'm pretty confident that it is possible to analyse substations if they contain for example transformers and also add tags based on this information for further usage in a separate database. Unfortunately I could not fully test this because the script that generates Overpass areas at the moment only supports the old tagging scheme with power=station/sub_station. I notified the maintainer via a PM on OSM but I'm not sure how long it might take to get this fixed since he seems to be busy elsewhere.--TOGA (talk) 23:23, 9 February 2019 (UTC)

Good point to look towards Overpass, the outdated preset you noticed will surely improve the querying over power grids. Anyway, querying the Overpass will only solve half of the whole problem:

• Functional features surrounded inside the substation perimeter => Overpass ok, the function can be flagged as yes on the substation
• No functional features inside the substation => Overpass doesn't see them, nevertheless we can't deduce anything. Should we look for them or flag the function as no?

Using processes tags on the substation itself will allow to run quality insurance tests, since it's not proper information redundancy. Inconsistencies will be reported. Fanfouer (talk) 21:25, 11 February 2019 (UTC)

You still have voltage=* to get hints. Different language, but with the MapCSS implementation in JOSM I can separate the string at every semicolon and get back a list, which then can be queried for the number of its members. So if you have more then one member you should be able to assume that the substation has a transformer. I'm not 100% sure, but regular expressions might even be more appropiate if you would simply need to look for a semicolon and don't want to do something else with a list of the voltage levels. Something similar can be done with frequency=*: multiple members -> converter; 0 as one of its values -> DC.

I also don't get how this would improve possible quality insurance tests. Why should I add a tag to the substation if I could just as well add for example a transformer at its location? You would probably also get a whole lot of false results when mappers just add the transformer and forget to add the corresponding tag on the substation.--TOGA (talk) 23:21, 18 February 2019 (UTC)

Seeing several voltages or several frequencies in lists doens't mean you have transformers nor converters to link them (although you have great chances to). Example in Strasbourg.

If a user put a transformer inside a substation that didn't expect to, QA tests will remind him to add the corresponding tag or to remove the transformer. Example in [Boismorand].

Hard work has been done on power=transformer to remove voltage=* with lists as values, then I won't be in favor of them on substations. Like frequency, voltage should remain as a device property. It's currently used as a comodity for substations rendering actually. Fanfouer (talk) 00:15, 19 February 2019 (UTC)

The substation in Strasbourg is interesting but are you sure that there are no transformers or what are those devices east of the 63 kV busbars? Of course they aren't 225/63 kV transformers but maybe step-up from the power plant via underground cables? I'm not really familiar with French layouts so I can just guess from the satellite imagery. The single 225 kV bay in the southeast corner is also interesting, I'm assuming there's also an underground connection to the main 225 kV section?

The specific QA test you're describing is possible with voltage=*. I also don't see the problem with lists for this tag as they can be analysed without any difficulties. By the way, if you want to eliminate the tag from substations you should probably add this to your proposal as the concepts are somewhat connected.--TOGA (talk) 23:19, 26 February 2019 (UTC)

Transformers in the Strasbourg place aren't in service any more (need to go there to see them). They use to be distribution transformers. Generation ones are in the plant next to the substation.

I've added a new paragraph about voltage=* on substations in Rationale chapter. It clearly stands that voltage isn't a reliable information due to current recommendations. We can't do QA test to look for transformers if there is only the highest value in voltage key. Fanfouer (talk) 23:20, 4 March 2019 (UTC)

Interesting, the dataset that you've linked below lists this substation as "POSTE DE TRANSFORMATION". Another error?--TOGA (talk) 23:07, 11 March 2019 (UTC)

Which is the French for substation. All substsations in the dataset get this function, even if there is no transformer like in Boctois. Fanfouer (talk) 12:34, 12 March 2019 (UTC)

Obviously you are the native speaker and not me, but I would definitely challenge the notion that poste de transformation just means substation. Wikipedia and IEC (605-01-01) agree that that would be poste, poste électrique or poste d'un réseau électrique. Poste de transformation would be translated to transformer substation, see 605-01-03.

Previously I randomly searched in the dataset for substations with other values, but didn't notice that on the left all existing values are listed and function has, as you say, only that single one. I don't really know what to think of this, but as it is that attribute seems to be pretty much useless?--TOGA (talk) 23:48, 12 March 2019 (UTC)

Ok that's right and agree to IEC 605-01-03. Anyway I also agree that the dataset POSTE DE TRANSFORMATION attribute is useless, I'll report it to data owner. I'm not sure you're convinced about the necessity of what is proposed here and what conclusions should we deduce here? Fanfouer (talk) 14:28, 13 March 2019 (UTC)

I might see some usefulness of the substation:<...> keys, especially with indoor substations where the individual devices etc. can't be mapped in a reasonable way but their existence is known. But, as written in the reason of my vote, the defaults are a problem in my opinion. I'll give some thought to this and get back to you later today or tomorrow.--TOGA (talk) 04:25, 14 March 2019 (UTC)

Thank you for your time. Defaults just translate what is currently implicit. When you find a substation=* you expects to find transformers, defaults are defaults what should I add to be more clear? The advantage provided by the proposal is now you have a tool to add information when available to change that default. Please think about it Fanfouer (talk) 08:31, 14 March 2019 (UTC)

Sorry for the slight delay. I disagree that an object tagged just with power=substation implicates the presence of a transformer. Of course a data user can make this assumption on his own but one has to expect errors this way. Applying your defaults will lead to errors. Take for example an indoor switching substation with no transformer but with no way to actually get this information, no open data, no detailed information board on the outside, etc. . The mapper can only map power=substation and location=indoor. With just this data and your defaults a consumer will now, falsely, think that there is a transformer. But what should the mapper do to prevent this? substation:transforming=no isn't an option since he/she doesn't actually has this information.

So my preliminary idea would be to allow the substation:<...> keys only on indoor substations since there's no way to map the layout of bays, transformers, etc. anyway. With outdoor substations I don't see a need for them, just map the actual device. The problem that I still have with this approach is how we ensure that these tags would really be only used in this way in the presets. I'm not sure if it's currently possible to configure presets in this way that these options become only available when location=indoor is selected.

Maybe we could also write a tutorial how to recognise the different devices of a substation from the ground and on aerial imagery so mappers are more encouraged to map them. I have to admit that I myself am little bit guilty of only mapping the substation outline and the incoming lines but not the devices themself. I already changed this in the last couple changesets where I also added the transformers. But I still have a problem with the busbars and bays since there are often ring or mesh layouts (at least that's what I think they are) used and I'm not really sure if these should be tagged as line=bay or line=busbar. At the moment I just don't map them.--TOGA (talk) 00:30, 17 March 2019 (UTC)

Not to mention all substation:<...> keys more stand for it should than there is actually. We converge on the fact that mappers sometimes can't have some informations but software can encourage them to find it. If you default substation:transformation=* to yes, then QA will warn you about a lack of power=transformer until you find them with a reliable source of information (or you explicitely put the flag to no). Fact is without such keys, we're not able to know if a lack of power=transformer in a substation means there is no transformer or they're not already mapped.

I certainly won't blame you to don't map a substation completly. That's how osm works, many people cant contribute at different times and we should be able to know if something is missing to encourage additional contribution.

Tutorial on how recognize is done on keys page : power=transformer, power=switch and power=substation or in French here. You have some nice place to look here or here.

Those are not using the layout that I have in my mind. I've tried to map a substation where a section (345 kV) is constructed with a mesh layout (IEC 605-01-20), so you can see what I mean. This one is also pretty simple as it's just a ring, in this substation outside of my current mapping area the bays/busbars are even crossing over one another.--TOGA (talk) 22:43, 21 March 2019 (UTC)

Understood but this doesn't regard the current proposal. We could discuss of the most appropriate way to map busbars later and on power=line page. Currently I would really appreciate you consider all explanations we have and confirm your vote please Fanfouer (talk) 15:08, 23 March 2019 (UTC)

Sorry for the late answer, I was away for a week. But to be honest, I also don't really know what I would've had to confirm. For me the negatives just outweigh the positives, so it was the logical choice to vote no on the proposal in its current state.--TOGA (talk) 17:49, 29 March 2019 (UTC)

Hierarchy definition

Hi Fanfouer, I don't see any mention of hierarchy in your linked definition, so I don't really understand your interpretation here. To me it looks like both transmission and conversion are listed in the same category Fundamental Concepts. --TOGA (talk) 04:24, 23 January 2019 (UTC)

Hi Toga, Hierarchy is implicit behind the fact transmission ties wider areas than distribution and distribution is usually fed by transmission systems. Thus distribution can be considered under transmission systems. Fanfouer (talk) 23:15, 23 January 2019 (UTC)

General remarks

Hi Fanfouer,

I think the main problem of the proposal is that you are trying to emulate IEC 601 and force it onto OSM. The tagging scheme should primarily cater the needs of the power mappers and nothing else. Your scheme will add unnecessary complexity; everything which currently can be expressed by a single tag will need two tags. And "negative" tags are generally discouraged. Which should I tag "substation:transformation/switching/conversion=no"? It would be much easier to just tag the yes case, which is standard in most parts of OSM. --Steenbuck (talk) 17:42, 3 February 2019 (UTC)

Hi Steenbuck. I'm a power mapper and IEC definitions has been helping us to get consistent tags for years. Necessary/Unnecessary are subjective, this proposal won't force you to use such tags if you don't want to. This proposal shows real issues with current tagging.

this proposal won't force you to use such tags if you don't want to. Sooner or later somebody will enforce your proposal. So please don't "play down" the consequences.--Steenbuck (talk) 13:38, 22 February 2019 (UTC)

Do you have examples of enforced tags in the past, here in OSM please? I use documented tags I like and find relevent. Fanfouer (talk) 17:25, 22 February 2019 (UTC)

https://josm.openstreetmap.de/ticket/9169 https://josm.openstreetmap.de/ticket/8847 https://josm.openstreetmap.de/ticket/15367 https://josm.openstreetmap.de/ticket/15365 Attempts in https://github.com/gravitystorm/openstreetmap-carto/issues/372 Mateusz Konieczny (talk) 19:05, 23 March 2019 (UTC)

Disagree. The tickets you provide are Post-vote cleanup after reviewed proposals. Can't you use discouraged tags any more? OSM would be hard to run without tags usage encouragement, which is slightly different from enforcement. Fanfouer (talk) 13:48, 24 March 2019 (UTC)

Lets phrase it as "Passed proposal influence OSM editors and mappers. As result winning vote strongly encourages winning tagging scheme and discourages alternative tagging schemes" Mateusz Konieczny (talk) 14:51, 24 March 2019 (UTC)

So it's not enforcement at all. If an alternative tagging scheme is more suitable than reviewed one, a new proposal should be voted (and be more than welcome). Please note that i'm blamed to have include substation=generation in the proposal because it wasn't documented at all. Some promoters edit the wiki on 2019-02-24. Which kind of enforcement is this? Fanfouer (talk) 15:09, 24 March 2019 (UTC)

I prefer to not argue about definitions, so I will not discuss it is enforcement or is a better name for that. But passing proposal votes were previously used to successfully request changing presets, adding validator rules and to encourage large scale retaggings etc. I am pretty sure that is what Steenbuck meant. Mateusz Konieczny (talk) 15:21, 24 March 2019 (UTC)

I respectably disagree that everything I propose can currently be expressed with a single key. Two tags are needed to describe situations given in example or in concrete benefits sections. Can you give me the tagging you could use with only existing substation=* regarding LVDC distribution substations or traction substations please?

You are evading my argument: It's a basic, unwritten principle not to use unnessarily many or complicated tags. You want to impose more tags on 99 % of the existing substations, which don't benefit from the new special cases listed under concrete benefits.--Steenbuck (talk) 13:38, 22 February 2019 (UTC)

Get me well, I only point out some limits of current tagging and propose optional solutions to get rid of them. As the document widely explains what the benefits are, I don't think it imposes anything to anyone. You argue that new tags are not needed, and I don't see any other possibility to share the conversion function between transmission and distribution levels. Fanfouer (talk) 17:25, 22 February 2019 (UTC)

As you may see in the List of applicable processes and default values by sort of substation table, the yes case can sometimes be implicit or default for hundred of thousand objects. Then it's better to tag the no case since it's the most unusual. Did you get that only 2 000 objects should be edited out of 300 000 existing? Fanfouer (talk) 23:11, 3 February 2019 (UTC)

Did you get that only 2 000 objects should be edited out of 300 000 existing? No, since basically every substation has switching functions and would get "substation:switching" by your new scheme.

That's not what I propose: substation:switching=* is optional and got yes as default for most substations. Only a very few of them will use it when there is no switching.

Example here. It's a transmission substation without switches whereas substation=transmission currently implies there are.

In countries without open data power mappers must visually identify the functions you are proposing. This means people have to identify the actual transformers and/or capacitor banks. Why should the mappers not directly tag them as nodes, but rather put these tags in a less exact manner at the substation outlines?--Steenbuck (talk) 13:38, 22 February 2019 (UTC)

Since they are discouraged to actually get inside substations, they won't be able to do so for indoor facilities. Public documentation (not proper open data) can implies there are features while you're not able to individually map them. Fanfouer (talk) 17:25, 22 February 2019 (UTC)

Example of simplest substation

I looked at several definitions and all of them state that a substation at minimum contains some equipment like switchgear or safety/control devices. Since that is not the case in this example, I'm wondering if it, strictly speaking, really is a substation. Maybe a separate value might be appropriate in this case? Of course this depends on how often such a configuration exists.
Little off-topic, but do you know what's the history behind this "substation". Why didn't they just build two higher towers so that the double circuit line going from the southeast to the northwest could cross the other power lines?--TOGA (talk) 23:54, 18 February 2019 (UTC)

According to wikipedia, an Electrical substation transforms or switches or performs other important function. This matches what is described in the proposal. Most of definitions stands for what is usual while this proposal deals with what is unusual. We not only need tags to map ususal things but particular and fewer situations also. This ensure us the tagging model is consistent and enoughly extensive to cover upcoming or missing use cases.

Regarding the simplest transmission substation, I think this would make towers too high or conductors too low and operator prefers to prevent any hazard or vulnerability. The place is fenced and secured like any other substation (with a big substation display on the gate) but is missing from official documentation. What an irony. https://opendata.reseaux-energies.fr/explore/dataset/postes-electriques-rte/map/?disjunctive.fonction&disjunctive.etat&disjunctive.tension&location=12,47.81742,2.79345&basemap=f91575 Fanfouer (talk) 23:30, 20 February 2019 (UTC)

Yes, but this specific "substation" performs no real function, not switching, not conversion, not transforming etc. . The fact, that it isn't listed in the official dataset actually supports my argument. I also looked at Landsat imagery and found that it was built sometime in 1985 so the reason for its absence can't be that it's just relatively new. Now, we do already cover some kind of pseudo-substations with substation=transition as these often also have no switching etc. . As stated above, the question is now how common such a configuration is and then we could think about if we want an additional tag like for example substation=crossing.--TOGA (talk) 00:01, 27 February 2019 (UTC)

A place where lines connect to each other is enough to define a substation. No specific function have to be running inside. The lack of tmy example sounds as a mistake according to operators' engineers. It may be added to the GIS shortly, we'll see. SUBSTATION is clearly stated on fence gate there.

substation=crossing will exactly suffer from the same problem I try to solve: what if I want to know if this crossing substation is part of a transmission or a distribution grid? Fanfouer (talk) 23:15, 4 March 2019 (UTC)

Don't you have the same problem with for example industrial substations? Those could also be fed from either the transmission or distribution grid, voltage=* will indicate this. Transmission substations can also be part of both and substation:transforming=* won't tell you if the transformation is between different transmission levels or also to a distribution level, voltage=* can do that.--TOGA (talk) 22:54, 11 March 2019 (UTC)

According to chart in Rationale chapter and public grid rules, industrial substations are dedicated to a single custommer and paid by him. There shouldn't be any transit of power through the substation to public grid. Then such substations aren't transmission nor distribution ones since they're not part of the public grid. Example with CERN industrial 400kV.

Current and proposed tagging never expressed the possibility to map from which substation a given node is fed.

A substation mixing transmission and distribution is first of all a transmission substation. More recently, such situations disappear and substations are split, like this one : transmission and distribution. Fanfouer (talk) 23:49, 11 March 2019 (UTC)

substation=delivery

Hi, it's a little unfortunate, that this only comes up after you already started the vote, but late last week I stumbled upon the term "delivery point" in a document, where it was used for describing the location where electricity is transfered from a transmission grid operator to the operator of a distribution grid. Initially I didn't think to much about it, but now that I reread the proposal something clicked at substation=delivery, so I checked the definition you linked to and sure enough it's delivery point. And there's also the note that the user of the electricity being delivered can be an organization for the distribution of electric energy to end users. Since I didn't think of it at the time, I don't have a link to the original document where I first saw this, but I did a quick search and on this site in the section at the bottom of the page it is used in this way: The transmission fee is based mainly on the amount of power drawn from the grid by distributors and power-intensive industries at delivery points. I think this is problematic, as substation=delivery could be misinterpreted as a substation where electricity is transfered from one operator to another and not just to an end user.--TOGA (talk) 23:42, 11 March 2019 (UTC)

Hi, this is a good point. There are delivery points and according commercial meters in pretty all substations. This doesn't mean that the whole substation is dedicated to delivery of power to a third-party user. I'll be vigilent to indicate it well since the substation=delivery (this is what is written on them, in the street like on my picture) is dedicated to end users. Grid operators aren't covered by this possibility. According to schema in Rationale, a substation=delivery can't be directly fed by transmission nor distribution levels. substation=minor_distribution is the only public grid item which can fed a delivery substation. I hope this dissipate doubts Fanfouer (talk) 23:58, 11 March 2019 (UTC)

substation=compensation

Second, compensation substations like this one: substation=compensation is needed for these cases. substation=distribution is clearly wrong in this case as the substation provides no distribution function. --TOGA (talk) 23:28, 13 March 2019 (UTC)

Well, distribution is not a function at all while compensation is actually. It's a hierarchical level according to rationale. You may find distribution substations without any custommer directly connected. I don't know what you expect to find behind distribution functions. Could you please explain it? Fanfouer (talk) 08:28, 14 March 2019 (UTC)

The comment for substation=distribution in your proposal is a good starting point:

A distribution substation is a substation whose main function is to feed distribution networks inside a given an area.

This can mean a couple of things, transforming to distribution voltage via a single or looped-in transmission line, switching distribution lines or also transforming between different distribution voltage levels if an area has multiple voltage levels for the distribution grid. In this case function is more meant like an umbrella function involving several subfunctions. Maybe as an analogy think of a car, the main function of which is to transport passengers. To do this you need numerous devices providing different subfunctions, engine to generate the driving force, drive train to transfer/distribute this force and so forth. Of course you could go even further and for example also dissect the engine into even smaller subfunctions. Perhaps role or task are also better terms?

Although the substation linked above certainly is part of a distribution network that's not what the tag according to the current description and also that in your proposal means. It doesn't distribute energy but rather is specialised just for compensation and hence deserves its own value.

And of course customers are not directly connected to distribution substations. I'm not sure where and how I gave that impression.--TOGA (talk) 04:27, 17 March 2019 (UTC)

We'll have to agree on our disagrement. Compensation is never done independently of the network which the substation is involved in. Then the role can be compensation, but the substation is involved in a distribution grid (not in a transmission one, the distinction should be made). It contributes indirectly of the reliable energy distribution since without compensation the operator have to spend more energy to feed all customers with a good quality of service. This is not the case for a private or industrial/traction substation because it only consume power without any transit or network service. Fanfouer (talk) 14:59, 17 March 2019 (UTC)

Distribution voltage

Hi, I run OpenInfraMap. Sorry I didn't spot this sooner. In general I think I'm happy with this, although openinframap doesn't use most of these tags anyway (the hierarchy is defined purely by voltage). A few minor technical comments:

• You say that "distribution" substations are those with a voltage lower than 100 kV, but in the UK parts of our distribution network (as defined legally) include substations at 132 kV. I would prefer that this wasn't specified and was left for local definition (e.g. this is covered in WikiProject_Power_networks/Great_Britain).
• It's probably worth making clear that generation substations are those which solely step up the voltage. In many cases this function is combined with transmission substations where the primary function is clearly transmission. I'm not sure why you don't also define a "substation:generation=" tag?

Russss (talk) 10:13, 18 March 2019 (UTC)

Hi Russss and thank you for your comments. I'm not the one who define the threshold of 100 kV to distinguish transmission/distribution. It's the current definition that remains the same through this proposal. I would also prefer to define this in local rules,but you can overload this on your own on the local page, like we did in French one.

As explained in rationale, voltage isn't the most reliable information available on OSM for substations but hopefully we manage to get usable renders out of it.

substation:generation=* isn't equivalent to conversion or compensation which are processes inside the substation while generation refers to a position in the grid. substation:transformation=* already includes any step-up or step-down of voltage/current activity. Fanfouer (talk) 17:46, 18 March 2019 (UTC)

Consequences of the proposal

Negative (no) tags are disregarded

The function of a substation should be stated with a bunch of (exclusively _optional_) yes/no tags Example

• • substation:transformation=no
  • substation:switching=yes
  • substation:measurement=no

IMHO this is fundamentally wrong. Functions should always be stated positively. What's not present should not be tagged to be not present! --Druzhba (talk) 19:00, 23 March 2019 (UTC)

Then how can we consider that expected missing functions actually don't exists? A missing value in your list or on the map can mean the feature doesn't exist or it should be mapped.

As current substation=* implies a consequent amount of concepts, (like we always find transformer in transmission substations) we definitely have to state functions negatively. Fanfouer (talk) 15:09, 24 March 2019 (UTC)

Why should pipeline stations and power substations mixed up in one scheme?

A power=substation and pipeline=substation currently use the same name for the subkey substation=*, which states the function.

Now both schemes should be unified. I think, that this is wrong since the only function they currently share is substation=distribution (distribution substations vs. gas pressure reduction stations). All other functions are exclusive to either oil/gas and power. --Druzhba (talk) 19:00, 23 March 2019 (UTC)

That's wrong and I disagree. Gas and power networks share at least transmission, distribution, minor_distribution, delivery and industrial. Generation can be extended to gas for production sites just like power plants.

Look at ENTSOE and ENTSOG which shares DSO and TSO terms to deal with companies that operate transmission or distribution networks. T and D respectively refers to Transmission and Distribution. Fanfouer (talk) 15:09, 24 March 2019 (UTC)

Massive retagging necessary

Fanfouer has evaded this question multiple times (e.g. [1]). Even if new tags are optional, they will become used over time. And they must become used if this proposal should have any purpose. --Druzhba (talk) 19:00, 23 March 2019 (UTC)

I didn't evaded this question, please refrain from stating things like this. The proposal state that less than 2000 objects have to be re tagged (differ from should) out of 300 000 existing substations.

I'm not responsible if some mappers would make optional tags mandatory, which is not what was proposed. Fanfouer (talk) 15:09, 24 March 2019 (UTC)

If a tagging scheme is officially adopted is becomes nearly impossible to tag "against" it any longer, because other mappers will correct you.

• There are currently 15.000 substations with power=transmission in OSM (Taghistory).
• Nearly 100 % of all major substations in the backbone power grid of any country worldwide (380 / 400 kV in Europe, 345 kV / 500 / 765 kV in North America, 345 / 500 / 750 kV in former Soviet Union), have
  • a transformer to the next lower power level (often 220 kV / 110 kV), so substation:transformation=yes
  • switches to isolate any circuits with faults, so substation:switching=yes
  • instrument transformer, that the central grid can see load flows, so substation:measurement=yes

Old	New
power=substation	power=substation
substation=transmission	(substation=transmission) kept
	substation:transformation=yes
	substation:transformation=yes
	substation:measurement=yes

This adds three additional tags, which are currently implicit. But you can't add these tags mechanically, because there are a few substations with only switch, but don't transform or STATCOM functions

This is a violation of the KISS principle.--Druzhba (talk) 19:00, 23 March 2019 (UTC)

This is precisely why those tags may be useful, to distinct specific situations from the common case with many implicit values Fanfouer (talk) 15:09, 24 March 2019 (UTC)

Traction substations

Traction substations of electrical railways should be tagged with substation:conversion=* by the proposal. In any case the frequency is changed, whether to "0" (DC), 25 Hz AC like in the US or 16.7 Hz like in Germany-Austria-Switzerland-Sweden-Norway.

This is less exact than the current tagging scheme with frequency=*. --Druzhba (talk) 19:00, 23 March 2019 (UTC)

frequency=* is a device property while substations are facilities. We can't be certain that mappers fill those keys with all values or with the highest one only. This need explicit tagging.

frequency=50	transformer → 25 kV AC (Europe, India, China, Japan)
frequency=60	transformer → 25 kV AC (USA, Korea, Taiwan, Japan)
frequency=50;16.7	Motor-generator → 15 kV 16.7 Hz AC
frequency=50;0	Rectified to DC, in most cases 750 V DC, 1500 V DC or 3000 V DC

--Druzhba (talk) 19:00, 23 March 2019 (UTC)

We do have plenty of traction substation which deals with DC which are tagged with frequency=50 since they are fed by 50Hz transmission power grid. This classification won't be meaningful I'm afraid Fanfouer (talk) 15:09, 24 March 2019 (UTC)

Benefits debunked

• Ability to indicate AC/DC conversion or not in substation=traction substations with substation:conversion=*. Currently it's not possible whereas trains systems not always run with DC power.

There is already a key for this called frequency, which is more powerful than the substation:conversion --Druzhba (talk) 19:00, 23 March 2019 (UTC)

Since frequency=* is a device property, no I'm sorry.

• Indicate a substation=distribution site contains power conversion ability for proposed Low Voltage DC network with substation:conversion=*. Currently substation=conversion implies substation=transmission only.

This is Siemens MVDC, which DOES NOT YET EXIST IN THE WILD --Druzhba (talk) 19:00, 23 March 2019 (UTC)

Here you will find a IEEE document or research paper (which is more meaningful that Siemens) document which introduce MVDC possibility. Nevertheless your point doesn't legitimate that substation=conversion should imply this is exclusively done on transmission grids. Fanfouer (talk) 15:09, 24 March 2019 (UTC)

• Indicate a (transmission mainly) substation doesn't involve transformers and it's not required to look for them in any (possibly hidden, at least indoor) place, with substation:transformation=no. Currently, all transmission substations are supposed to host transformers while a very few of them actually don't. voltage=* is not reliable for that, according to rationale.

Valid point --Druzhba (talk) 19:00, 23 March 2019 (UTC)

So does frequency=* and any device property reported to surrounding facilities. Fanfouer (talk) 15:09, 24 March 2019 (UTC)

• Distinguish dedicated power generation plant substations with substation=generation from current substation=transmission.

Already there since 2014. Fanfouer hasn't invented this. --Druzhba (talk) 19:00, 23 March 2019 (UTC)

Not invented but start its documentation. substation=generation was created on 2019-02-24. How can everyone be aware of this if promoters don't document it? I revert some updates in wiki since the beginning of the RFC of this proposal because some contributors want to make it kind of reviewed prior to the vote. Fanfouer (talk) 15:09, 24 March 2019 (UTC)

According to Rationale, power plants can actually produce low voltage power with distribution grid direct connection. substation=transmission isn't always suitable for them.

What's the point here? Does anybody understand this? --Druzhba (talk) 19:00, 23 March 2019 (UTC)

power=generation is required if we want to make a distinction between transmission output and distribution output power plants. Since substation=generation was not documented, mappers were encouraged to describe step-up voltage substations with substation=transmission. Fanfouer (talk) 15:09, 24 March 2019 (UTC)

• Share equivalent transmission, distribution and delivery concepts between power and pipelines.

WHY? --Druzhba (talk) 19:00, 23 March 2019 (UTC)

Because it's objective reality. Pipelines deal with transmission, distribution, minor_distribution, delivery and industrial concepts also. See [2] Fanfouer (talk) 15:09, 24 March 2019 (UTC)

• Introduced processes keys can be easily completed with any new process defined in the future (not currently known nor defined). Values can be improved as soon as the knowledge get better regarding the existing ones also (like what is done for converter on distribution grids edges). This proposal introduce a kind of framework for power/pipeline processes and don't lock things since IEC definitions are exhaustive for current industrial state of the art only.

The principle of OSM is the extendable tagging scheme. So this is a fake argument --Druzhba (talk) 19:00, 23 March 2019 (UTC)

Didn't understand that point. Fanfouer (talk) 15:09, 24 March 2019 (UTC)

Effect on nonspecialist mappers

This is a very detailed proposal that is rather inaccessible to people like me who are relatively unfamiliar with electrical infrastructure. Woodpeck pointed out in the vote that field-surveying some of the tags here seems to require not only specialist knowledge but also access to restricted areas. What practical effect will this proposal have on the ability for nonspecialist field mappers and armchair mappers to contribute more basic information about power infrastructure that they encounter? I would appreciate this clarification before I can feel comfortable enough to vote one way or another. Thank you. – Minh Nguyễn ^💬 20:23, 23 March 2019 (UTC)

@Minh Nguyen: Hi Minh, as I've pointed out above, this proposal has no real concrete benefits. If you agree on this may you please be so kind to vote against it and not only abstain from voting? Fixing a proposal after it was voted down is much easier than to live with a deficient, but official proposal.

Kind regards --Druzhba (talk) 20:31, 23 March 2019 (UTC)