Proposal talk:Traction substations extension

Replace conversion concept with explicit input and output characteristics

I would suggest having input {frequency, voltage, phases} and output {frequency, voltage, phases} instead of the proposal for conversion=acdc etc. This would allow for any combination of inputs and outputs and it would be immediately obvious which conversions are taking place. The conversion mechanism might get some added detail, e.g. rotating, solid state, (auto-)transformer etc if required. --Csmale (talk) 16:45, 4 May 2019 (UTC)

Thank you Colin for this comment. Are you sure it would be ok to make devices properties redundant with substations' ones? This proposal aims to separate properties of devices and properties of sites/surrounding perimeters. I would like to avoid any frequency, voltage or phase on substations objects since these are device properties. Fanfouer (talk) 14:24, 5 May 2019 (UTC)

I guess my problem is because I don't understand what the goal is of this proposal. A substation is a substation, and there is nothing magic about a traction supply, except that there are conversions of phases/frequencies/voltages that you probably won't find in the normal national power grid. If it is your intention to give a way of representing some (traction-specific?) characteristics, why is the number of phases (input/output) not relevant? Conversion between AC and DC occur in the national power grid as well, and are not specific to traction power. Unless there is something really traction-specific, it would be better to refine the current tagging of substations instead of limiting this proposal to traction supplies. You want to separate the "site" characteristics from the "devices." These technical characteristics are indeed associated with the equipment contained within the site; the function of the site as a whole is (in the terms you seem to be aiming at) the sum of the functions of the components. On a single site, there might be multiple things going on - I am thinking particularly of Switzerland where you may have multiple voltages within a single station, which could all be fed by a single substation (although I don't know the details of how they arrange this in practice). I guess what I am trying to say, is that there is nothing traction-specific here, at the abstraction level I have in mind. Zoom out a bit, and you will see they are just substations. --Csmale (talk) 15:14, 5 May 2019 (UTC)

I think we broadly agree. I firstly intended to refine the whole substation concept with this proposal which was down voted because it was too big and not well packed (skip to final comments on Talk). That's why I'll focus on particular processes in several documents to reach consensus on each point separately.

It's ok to say phases (and frequency, voltages, whatever) changes are relevant, but not particularly on substation perimeters. Such information can go on phases:primary=* or phases:secondary=* (respectively voltage:primary=*, voltage:secondary=*...) for power=transformer or power=converter devices. As you point out there can be complex processes going in the substation, it may be harder to describe them all on a single perimeter feature instead of mapping as many equipment as possible with appropriate tagging. Then the proposal is intended to provide a simple key to put the process name on the perimeter and encourage people to look for corresponding devices to give more details about it (which is not enforced, mandatory nor always possible). I've updated one of the example substations to give a better insight of how it can be achieved. Fanfouer (talk) 15:58, 5 May 2019 (UTC)

Values in the proposal are only examples

Resolved: Edits done and proposal made without concern about phases Fanfouer (talk) 14:22, 5 May 2019 (UTC)

Where values are shown in the text, e.g. 25kV or 50Hz, it should be made clear that these are only examples. There are some weird traction systems in use in the world, including 3-phase overhead, different non-standard frequencies and split-voltage 4-rail systems. This proposal needs to allow all these combinations, and not subconsciously view things through a particular perspective. --Csmale (talk) 16:51, 4 May 2019 (UTC)

Converters hidden in building

Hi fanfouer,
you're mentioning possible converters hidden in buildings, but I don't get in what way your proposed key would solve such a problem. In the case I don't know, if a converter exists or not, I also cannot apply this key. On the other hand if I do know, that there has to be converter in a substation, I could either simply tag the building outline with power=converter or add a separate node like you did above. Additionally if I don't know the number of devices, I'd add a note=* saying that there might be multiple converters.--TOGA (talk) 22:30, 8 May 2019 (UTC)

Hi Toga. You may know there are converters because the connected railways run in direct current while the public grid provides alternative power (for instance). As you may not be able to map precisely power=converter devices, you can add conversion=acdc on the substation perimeter with your local railway knowledge and let others do further improvements to add converters if possible (this is not mandatory). This is more queryable and formalised than free text note=*, aren't you? Fanfouer (talk) 22:44, 8 May 2019 (UTC)

Sorry, I cuold've worded that a little bit differently. What I was trying to say is that this specific problem of converters hidden in buildings can, in my opinion, be already solved satisfactorily with the current tags. If someone has so much knowledge in this field that he or she can infer that there has to be a converter by looking at the voltages and frequencies of the railway and feeding power line that knowledge should also suffice to roughly locate the converter.

With regards to the note=*: This is of course not meant as a stand-alone tag. Taking your example, instead of the three nodes you've mapped, you could also just add a single node with power=converter and a note=* saying that there might be more than one converter if you're not sure how many there really are. Alternatively fixme=* might also be considered as an option.--TOGA (talk) 03:32, 16 May 2019 (UTC)

Since power=converter isn't compatible with building=* (a converter is a device and building isn't), it's less possible and desirable to use building=* + power=converter + note=There should be several converters in this building. How could we feed a reliable QA test with a free text note? Fanfouer (talk) 23:01, 16 May 2019 (UTC)

The classic QA-tag is of course the above-mentionend fixme=*. So depending on how strong of a message you want to send to other mappers, that could indeed be the better key. In the end the key fixme=* then enables highlighting in QA-tools and the free text value provides additional information to mappers what exactly can be improved.--TOGA (talk) 18:31, 23 May 2019 (UTC)

Then, why OSM needs tags anyway? Any objects can be tagged with fixme=It's a highway with trees along or fixme=Look a this trafic light, with pedestrian crossing in front of it. Fixme is a placeholder for undocumented situations and you raise the argument it should be used to prevent further documentation. That's not its purpose Fanfouer (talk) 23:52, 30 May 2019 (UTC)

No, fixme=* isn't a placeholder for undocumented situations, it's a QA-tag to highlight things for other mappers or oneself that could be improved. The values that you're giving as examples would better fit into description=*. An example for the usage of fixme could be the be following: imagine being on a walk without a GPS-capable device and you spot a hunting stand, back at home you add the hunting stand roughly where you remember it and add fixme=resurvey; postion estimated from memory. Another example could be a new residential development that's not yet available on aerial imagery. While streets are easily mapped with a GPS-device, buildings are more difficult and one could add something like fixme=position and shape estimated from ground survey;improve with future aerial imagery to them.

Now take the third example from your proposal and for the sake of the argument assume that somehow a mapper just only knows that there has to be a converter in this substation but cannot locate it (again, as written above, I'd argue that if a mapper has that much knowledge about power infrastructure he should be able to deduce that the converter/s is/are in the building, but that's another point): In this case I would indeed advise to simply add a fixme to the substation outline.

Regarding the points below: Unfortunately I have to go now, but I'll try to respond later today or if not by then at the latest on the weekend.--TOGA (talk) 03:18, 7 June 2019 (UTC)

The main point of the proposal is to document industrial processes with formal tags. Even if we can make fixme=* suitable for users to let message to their mates asking for correction, it's not the original goal. I strongly disagree to build any tagging strategy based upon a free text attribute. Free text and documentation is kind of real antagonism, this doesn't require formal proposal but it's not suitable to industrialise the search of converters in public data, computer vision data sources or any information not coming from human. Fanfouer (talk) 19:41, 7 June 2019 (UTC)

Toga : our idea to add node at a fake localtion+fixme=location+fixme/note="maybe more that one" to avoid one new structured tag is very UGLY. osm already makes often a differences between characteristic of a site and device needed for this characteristic. a characteristic is not an error that must be corrected even if it can then be used to add more device (an unmapped device is also not an error requiring a fixme). see my full reply Marc marc (talk) 23:27, 7 June 2019 (UTC)

Sorry if there might have been a misunderstanding but I never suggested to add a node at a random fake location or at least it certainly wasn't my intention. If you take a look at the third example from the proposal and assume that we know the voltages/frequencies of the railway and the feeding power line and thus that there has to be a converter in this substation, I think that it's pretty obvious it has to be somewhere in the building. Now you have two options what to tag with power=converter: either the building outline itself or adding a node inside of the building close to where you assume the converter to be. With regards to the note: If you look at the picture again, you'll see 3 transformers each with a separate connection to the building. This definitely is a strong hint that there might also be 3 separate converters but it's not certain. Because of this I would also add something like note=possibly up to 3 converters as there are 3 transformers with separate connections to the converter building to the feature tagged as the converter. In this case I wouldn't use fixme because this is all on private, closed property out of sight and so getting this information is relatively unlikely and entirely dependent on the company releasing open source data.--TOGA (talk) 17:48, 8 June 2019 (UTC)

Futhermore, as power=transformer or power=converter are devices, they shouldn't be compatible with building=*. It is recommended to map them as nodes, eventually enclosed in a building polygon if needed. This is for sake of One_feature,_one_OSM_element principle. Fanfouer (talk) 22:50, 8 May 2019 (UTC)

Considering that converters are often housed in separate converter halls, I think it might be appropriate to tag them on the buildings. This also has the benefit that the network itself is more routable. If I take a look at the current statistics, this also seems to be the dominant mapping practice with 80% being mapped on ways according to taginfo. Similar mapping happens with for example shops that occupy a whole building, as those generally get tagged with building=* and shop=* on the same outline.--TOGA (talk) 03:32, 16 May 2019 (UTC)

Prior the refactoring of power=plant vs power=generator, power plants used to be mapped as generators. Then I won't rely on statistics and current usage as I try to change this precisely.

That's not because a device is (often) housed in a dedicated building that the building should get the device's attributes. This would break One_feature,_one_OSM_element principle.

How merging sites with devices will ease network routing?

Finaly, shops and buildings are sites, not devices. You should deal with fridges inside a given shop to be comparable to converters inside a building. Fanfouer (talk) 23:01, 16 May 2019 (UTC)

The reason why power=generator was tagged onto the whole outline of power plants was more likely the messy tagging scheme with power=sub_station/station/generator. With some interpretations of this scheme where sub_station and station were meant to be different sizes of substations, you were just left with generator to pick for power plants. Nowadays the tags are of course much better and that confusion is solved. Even today however power=generator gets tagged on buildings as described on its wiki page:

"If the generator is contained within a building (such as with a nuclear reactor or hydroelectric turbine), the generator can be tagged as a node, or the smallest building containing the generator can be tagged."

If current mapping practices are immutable, then how can proposals improve the whole thing? To me and according to the experience we have with infrastructure and technical facilities, it's not great to assume buildings as devices. It can confuse mappers (for example sating that a distribution substation is a transformer is wrong: you have many other equipment in such substation to resume it all to a single transformer). Consummers currently have to look for many possibilities for a single concept. Fanfouer (talk) 23:52, 30 May 2019 (UTC)

Of course mapping practices can be changed but I think the hurdle for changing existing tagging versus entirely new schemes should definitely be higher. Many years after the successful proposal regarding substations we can still find the old tagging in the database. I think that emphasises why one has to be careful with existing schemes.

The problem with the mistagging of substations as power=transformer is, I believe, rather a language problem than a confusion between sites and equipment. At least in German these minor substations are called "Transformatorenstation" or colloquially "Transformatorenhäuschen" literally meaning something like "little transformer house", little refering to the house. With that in mind I can absolutely see why some mappers might be tempted to use transformer instead of substation.--TOGA (talk) 23:13, 8 June 2019 (UTC)

This actually is also in line with "One feature, one OSM element". The first point under Examples of bad situations describes exactly this and the same, in my opinion, applies to converter halls.--TOGA (talk) 18:31, 23 May 2019 (UTC)

I disagree : you have a building and a converter inside. It's two features, not one! Fanfouer (talk) 23:52, 30 May 2019 (UTC)

Yes, it's a building with a converter inside, but it is a single-use building. Take for example a look into this document (page 3): The converter basically fills the whole building. Yes, there are small siderooms for cooling and control, but those are just supporting the main single use. Additionally I'd argue that this isn't even that different from the above mentioned shop, those also have supporting areas like storage places, rooms for employees, surveillence room, administration etc. .--TOGA (talk) 23:13, 8 June 2019 (UTC)

I just checked the history of Tag:power=converter and the approved proposal which it is based upon. Originally it explicitly recommended to add power=converter to the valve hall (building containing the converter). When you added more detail to the wiki page, you removed this to state that converters should only be mapped as a node. Since the approved proposal says otherwise and the common mapping practice, as shown above, agrees with this, I'll change this.--TOGA (talk) 21:14, 23 May 2019 (UTC)

Thank you Fanfouer (talk) 23:52, 30 May 2019 (UTC)

Consider laws and regulations might differ, preventing power=converter on a building=* can prevent some features from being mapped. We also have the power=switchgear which would be placed on a GIS building. This is quite similar. Question is how far do we go? The converter is technically not a single device either. Gazer75 (talk) 06:39, 24 October 2019 (UTC)

Can you elaborate a bit more on how regulation can prevent to map features inside buildings while allowing to add tags on the building itself please?

A switchgear isn't a proper device (composed of power=switches and line=busbar). How far we go question applies also on power=generator : we should tag things that are consistent with the extent given to the used key. If we intend to describe components of the converter, then we shouldn't use power=converter but corresponding terms. See this attempt to go deeper inside a nuclear generator: [1] Fanfouer (talk) 18:45, 24 October 2019 (UTC)

There is a limit to how much we can legally map in Norway before breaking §6-2 of the power readiness regulation (Google Translate works on the text). It is to much to write here, but basically adding indoor items that are not public info is not good. Technically I could only map substations as a node with with name and operator if I were to follow this to the letter. But after talking to people dealing with this stuff every day I was told info already public like aerials and other public documents would be fine to map. I am trying to not go to far, and thus I map things on building. Detailed info on what is in side is not something I am supposed to know or spread if I do. §6-2 is, according to §1-3, applicable to anyone not just the power companies.

Take the Skagerak 1-4 HVDC converters at Kristasand substation. Adding nodes with converter inside buildings would disconnect them from the lines completely. Also, where would the converter be placed? We don't know and should not know this. Mapping lines inside would be going to far IMHO. Gazer75 (talk) 19:33, 24 October 2019 (UTC)

Voltage tag for 2x25 kV AC traction system

Resolved: Voltage has been updated Fanfouer (talk) 19:19, 19 February 2021 (UTC)

Hi, I have a note not about the proposal itself, but about the first example - the autotransformer site for 2x25 kV. I think that it would be correct to tag it with voltage=50000;25000, not just voltage=25000.

Let me explain. For common 3-phase lines in OSM we use single value of voltage tag, because if you take any 2 from 3 wires, the voltage between them will be equal (and equals to the value from tag). So, we can say that all possible voltages, thar we can get from this line, are mentioned.

2x25 kV AC traction system in also 3-wire system: running rails, catenary wire and feeder transmission line. But in this case if we take 2 of 3 wires, we can get different voltages: catenary & running rails - 25 kV, feeder line & running rails - 25 kV, but between catenary & feeder line - 50 kV. So, both voltages, which are given by this line, should be mentioned. Additional profit is that data user can distinguish 2x25 kV traction substations from common 25 kV ones - by presence of 50000 value in voltage=*.

That's right, thank you for this comment. I've updated the voltage to 50000. Fanfouer (talk) 19:19, 19 February 2021 (UTC)

Great, but why not 50000;25000 , as for any other multi-voltage substation? Presence of transformers implies that we are operating on more that one vlotage value. AnakinNN (talk) 07:59, 29 March 2021 (UTC)

voltage=* is suggested to be the highest value for multi-voltage substations. Semi-colon lists should be avoided and are not so convenient to process afterwards. A substation is a facility and doesn't convert any voltage, consumers should look directly on transformers to see what is actually done there. There is many other voltage live in such a substation both medium and low voltage for command and control, sensors, auxiliaries, whatever.

We could use design=* with a concise set of values to describe how traction substations are built if relevant Fanfouer (talk) 14:00, 29 March 2021 (UTC)

But now wiki says: When multiple voltages are in use, for example on a power line carrying two circuits, or a substation converting between two voltages, the voltages should be separated by semicolons with the highest voltage listed first: voltage=275000;132000. And as I can see, this tagging is widely used in different countries, so we need separate proposal, if we want this to be done in the other way. Also, there is frequent case, when we don't know exact internal structure of substation, but can observe public sign on the fence, where all voltages are listed - example (voltage=110000;10000;6000), another example (voltage=110000;35000;10000) AnakinNN (talk) 17:46, 29 March 2021 (UTC)

The page has been edited since Proposed_features/Substation_functions discussion. It used to be can instead of should.

Anyway, using 50000;25000 here would conflict with your first comment as +/-25000v wires are part of a 50000v system. Considering all available voltages here would lead to -25000;25000 instead of single 50000 for substation's design voltage. I don't get when we have 50000;25000 for such situations.

I'm ok to describe the reality but I also learnt from previous proposals to don't deduce anything from voltages. If you need to distinguish these facilities from others, then we need accurate tagging for such and not list of voltages Fanfouer (talk) 20:19, 29 March 2021 (UTC)

Well, I'm think, that this question is outside this proposal, which in mainly concentrated on frequency_conversion tag. I suggest that it was pointed at the start of examples section, that only highest voltage is given in the voltage tag below. It should clarify situation to all readers AnakinNN (talk) 20:38, 29 March 2021 (UTC)

The proposal is about traction substations extension, including frequency conversion tag but nothing prevent to discuss about voltages as well Fanfouer (talk) 20:54, 29 March 2021 (UTC)

conversion=yes (value without more precision)

Resolved: Yes value added to proposal Fanfouer (talk) 19:19, 19 February 2021 (UTC)

standard value when the contributor does not know or does not want to fill in a more precise value or when it is not yet defined --Marc marc (talk) 11:13, 19 February 2021 (UTC)

I wasn't in favour of adding it in the beginning. However it would certainly help people who don't want/can't give any more details. It's now in the proposal Fanfouer (talk) 19:14, 19 February 2021 (UTC)

ac-ac back-to-back converters : missing value ?

how to tag a traction substation with a ac-ac back-to-back converters : missing value ? --Marc marc (talk) 11:15, 19 February 2021 (UTC)

Proposal introduces conversion=ac_ac for such situations Fanfouer (talk) 19:12, 19 February 2021 (UTC)