Proposal talk:Power circuits routing

Remarks about verifiability

During the vote occurring from 2025-05-26 to 2025-06-09, several comments raised about verifiability:

• Hardly verifible and lack of easy ground truth. @Riiga: 11:13, 26 May 2025 (UTC
• There's nothing in this proposal about how to map or verify this data. @SomeoneElse: 13:50, 26 May 2025 (UTC)
• Also, planned mapping methods conflicts with "Everything required to make such an assembly is available on ground" claim. @Mateusz Konieczny: 13:08, 26 May 2025 (UTC)

An example is proposed on community forum, based upon SomeoneElse's 207456692 207456692 case. It's in addition to several How will we get such information? chapters in the proposal itself. What kind of information or conflicts should we solve to make it clearer please? Fanfouer (talk) 17:01, 26 May 2025 (UTC)

What about resistance impedance reactance which is also part of that proposal? Mateusz Konieczny (talk) 00:39, 27 May 2025 (UTC)

I encountered situations where physical properties were printed on ground, so basically it's the same for them. Down voting a key because someone could violate core principles of OSM isn't very fair. I could have imported highways from proprietary sources if I wanted to but no one discouraged anyone to map highways from suitable sources. Anyone who wants to bulk import something should discuss it first and this proposal doesn't propose a particular import. Question asked are more should we model physical properties or line capacity? Is it consistent to associate physical properties to physical lines or should we prefer circuits? and so... This proposal introduces placeholders for knowledge when appropriate source are available. Imports may be discouraged for various reasons and approved keys don't make it automatically legit Fanfouer (talk) 06:24, 27 May 2025 (UTC)

Topology key seems like duplication

The `topology` key seems like unnecessary duplication, as the number of `substation` directly implies `linear`/`branched`. @Jofban: 14:17, 26 May 2025 (UTC)

The topology key allows to define the actual situation without being able to find all substations on ground. It's true the number of substations involved allow to deduct but this deduction can be used in quality control too check if it is consistent.

Sometimes, on ground you may see 3 substations names written on towers but the 3rd is not yet mapped in OSM and you didn't find it yet. Then you use topology=branch to prevent anyone to consider it as linear. Fanfouer (talk) 17:01, 26 May 2025 (UTC)

Sourcing from open data and statistical model

The proposal repeatedly states that the information is not ground observable and should be sourced from other open data. In one case it even suggests to use statistical models to guess. Doesn't make sense to have in OSM. Rather seems to be a good candidate for creating derivative data from OSM and other sources. @Lonvia: 12:12, 26 May 2025 (UTC)

I guess this is about physical properties. This proposal doesn't force anyone to look and find the data to contribute. But we currently struggle to maintain information from people who want to contribute on that particular matter so that's how we could improve it. By the way, I don't see any mention of statistical model to find the information, where had you read it? Fanfouer (talk) 17:01, 26 May 2025 (UTC)

"How will we get such information?" mentions "Public information, scientific datasets or open data could help find impedance, resistance and reactance as many scientists and researchers currently build static network models." - I understand this as importing data from these statistical models would be one of sources Mateusz Konieczny (talk) 00:36, 27 May 2025 (UTC)

A static model isn't statistical, why are you assuming it is? Static is opposed to dynamic, it's physical properties that doesn't change over time Fanfouer (talk) 06:07, 27 May 2025 (UTC)

OK, so that is next level of confusion: I expect network models to be statistical models, it is not coming from static part. Though if I would be writing I would focus on model part, not statistical part Mateusz Konieczny (talk) 07:55, 27 May 2025 (UTC)

OSM data could be used to build network models combining statistical and dynamic data if required. However, this proposal only focuses on static knowledge. It's not relevant to mention the statistical part here Fanfouer (talk) 08:06, 27 May 2025 (UTC)

Why against type=route?

Resolved: proposal has been improved without change in meaning

I also don't understand the reasoning against `type=route`. Sure, it's not public transit, but there are also bike routes. @Jofban: 14:17, 26 May 2025 (UTC)

Bikes routes and public transit relation are used by the same kind of software. Currently having route=power force them to filter as not getting cluttered by relations they won't ever consider. It's just like waterways aren't routes for water, there is type=waterway instead. Fanfouer (talk) 17:01, 26 May 2025 (UTC)

The current argument boils down to "Electrons don't move like people" whereas the argument I believe you want to make is "Electrons/Power aren't people", i.e. `type=route` is for routes where people can travel on (perhaps using particular vehicles) and power lines are certainly not used for that. Jofban (talk) 20:31, 26 May 2025 (UTC)

Electrons don't move, it's a fact. It's more related to force than matter. By the way, is it clearer for you why the proposal doesn't promote route=power? Fanfouer (talk) 06:27, 27 May 2025 (UTC)

Thinking about it myself (and consulting the relevant Wiki pages), I came to agreement with you that type=route route=power doesn't fit. However, the reasoning has nothing to do with how power is transmitted (I'm aware that charges don't move in AC circuits), instead focusing on the aspect that type=route are routes for people, which transmission lines aren't. Jofban (talk) 10:53, 27 May 2025 (UTC)

The sentence Also there are no traveling things like buses, passengers or travelers as in "common" routes. seems to summarize the difference about human traveling. Should I rephrase it? Fanfouer (talk) 17:34, 27 May 2025 (UTC)

Yes, please rephrase it. Honestly, you could probably replace the entire section except for the last line with this quote from type=route: Routes consist of paths taken repeatedly by people and vehicles. Simple, but effective. --Jofban (talk) 20:57, 27 May 2025 (UTC)

I've quoted directly from type=route but the point about routing software and route=* lower cluttering remain valid. Fanfouer (talk) 09:18, 28 May 2025 (UTC)

You somehow made that section worse, and with your response, I think it's an attitude issue. To put it bluntly, the first paragraph reads like this: You all don't know how electricity works, so I understand that you can't see the difference between a power line and a hiking trail. But fortunately, I got a degree in EE, so I can tell you that they are, in fact, different. The way it is written insinuates quite a condescending viewpoint, no matter how correct the reasoning might be. As for routing software: Keep your reasoning simple. The tagging is wrong, leave it at that. Jofban (talk) 11:54, 28 May 2025 (UTC)

I've no EE degree and I'm not the original author. I had in mind to also respect what precedes us in this common build but it wasn't clear. Fanfouer (talk) 18:00, 28 May 2025 (UTC)

Why aren't we prompted for capacity in MW?

I understand your explanation, but is that an argument not to mention a max MW? When I buy a certain AWG rated wire it also says AWG8 ~ 40 Amps. We all know that then we need to calculate the MCB using the formulas and tables for ambient temperature, core numbers, free air vs wall installation, TW/U/THW-2/ZW-2, etc and many more factors. Why should it be prohibited for a mapper to mention MW, analog to the 40 Amps I read on the AWG8 knowing it depends on so many other factors what rating I should choose for my breaker?

Hello. We avoid that because this 40 amps mentioned regarding AWG8 also depends on hypothesis and we don't always know under which hypothesis (nor from which conductors they are built) are stated power lines ratings. Sometimes it's the average, elsewhere it's summer maximum and so on. It's first of all because it won't be comparable on different power lines and secondly because those value have high chances to be mistaken. We would need a more elaborated tagging to modelise rating hypothesis with sub keys to solve that kind of problems. Fanfouer (talk) 09:14, 7 July 2025 (UTC)

So if I understand you correctly, we can't do this because a max-rating isn't possible for these power lines? --Hike&Map (talk) 01:20, 8 July 2025 (UTC)

Theoretically, max rating is always associated to a given amount of time during which the rating is reach. And in practice we don't know if the displayed rating is the max, or the average, or the max under certain circumstances. We would introduce a risk by only asking for a value in MW without defining much precise framework most mappers won't be able to match anyway. Fanfouer (talk) 08:00, 8 July 2025 (UTC)

Thank you I understand now, you're right for home appliance the max ratings here on the wires are for constant predefined temperature range and predefined amount of cores and cables and then based on the situation you calculate down what breaker has to be used. Thanks for clarifying that for these big power lines that's not how it works --Hike&Map (talk) 08:48, 8 July 2025 (UTC)

It's a complex topic and it would be perfectly fine to think about how we could reduce the risk and make it finally suitable in OSM afterwards this proposal. It was important to go step by step and to begin with discouraging to map values in MW. Fanfouer (talk) 11:01, 8 July 2025 (UTC)

First vote results

A first voting attempt took place between 2025-05-26 and 2025-06-03:

• I oppose this proposal. Hardly verifible and lack of easy ground truth. --Riiga (talk) 11:13, 26 May 2025 (UTC)
• I oppose this proposal. Seems to combine failing verifiability by the ground survey and relations with complexity similar to public transport. Also, planned mapping methods conflicts with "Everything required to make such an assembly is available on ground" claim. Maybe technically "circuit breakers, which are typically located within substations" are available on the ground but it does not make them surveyable Mateusz Konieczny (talk) 13:08, 26 May 2025 (UTC)
• I oppose this proposal. There's nothing in this proposal about how to map or verify this data. SomeoneElse (talk) 13:50, 26 May 2025 (UTC)
• I oppose this proposal. Wire diameter should not be mapped, because we can't get that info, but impedance should? All arguments for or against the former also apply to the latter. I also don't understand the reasoning against `type=route`. Sure, it's not public transit, but there are also bike routes. Lastly, the `topology` key seems like unnecessary duplication, as the number of `substation` directly implies `linear`/`branched`. --Jofban (talk) 14:17, 26 May 2025 (UTC)

-- Comments has got answers on talk page. Mind having a look at it when voting please

• I oppose this proposal. This is definitely not KISS anymore. --chris66 (talk) 07:22, 27 May 2025 (UTC)
• I approve this proposal. The description is long because detailed but improves modelisation of this topic in OSM and quality control tools exist to detect incoherencies in the data in the long run. Thanks for the effort in the redaction of this proposal. --Pogregoire (talk) 10:37, 27 May 2025 (UTC)
• I have comments but abstain from voting on this proposal. I love how detailed you documented everything here and you clearly know what you're talking about. But I don't know enough about it to know if it's indeed as unverifiable as the others here are saying. --Thibaultmol (talk) 13:19, 27 May 2025 (UTC)
• I approve this proposal. --Ddtt92 (talk) 15:34, 28 May 2025 (UTC)
• I approve this proposal. --Michi (talk) 16:00, 29 May 2025 (UTC)
• I approve this proposal. Fanfouer (talk) 07:33, 30 May 2025 (UTC)
• I have comments but abstain from voting on this proposal. In fact, I approve this proposal. Nevertheless, my company Jungle Bus being involved as a subcontractor in the Oh My Grid initiative, voting YES would be a conflict of interest, so I request that my vote is not taken into account. I think that the perceived complexity comes from the fact that the topic is technical and specific. It shouldn't stop us to approve it: some networks are complex and hard to describe in OSM, and that's perfectly normal. We already face a precedent with the Public Transport model, and this complexity did not stop us from using it. Now, the electric grid seems a promising topic, and the applications are countless as soon as the power network becomes truly routable. This is the aim of this proposal. Also, I believe that every condition is respected: the verifiability criteria is not violated. Therefore, it's not a topic limited to open data integration but involves a proper ground collection task. --Overflorian (talk) 09:25, 2 June 2025 (UTC)

Wait, where second vote was announced?

I have not noticed announcement of a second vote.

Where it happened? It also seems to be not listed on the page itself

Mateusz Konieczny (talk) 20:23, 10 July 2025 (UTC)

It has been announced on community forum, just like the first attempt, lately on French community forum and then in last OSM Weekly as well. It also been relayed on OpenMod forum and several discord and matrix channels. Fanfouer (talk) 20:51, 10 July 2025 (UTC)

This does not look like a valid announcement: it is hidden in an existing thread. You are also not mentioning posting on mailing list. It does not look like a valid vote to me Mateusz Konieczny (talk) 10:24, 11 July 2025 (UTC)

It wasn't hidden as it brought the topic on top and anyone could see it. I'm not seeing every announcement too and if would like to, I could monitor the Voting category on wiki. Fanfouer (talk) 13:55, 14 July 2025 (UTC)

Trunk/branch vs sections

I'm happy with the proposal, but I think that outright dismissing the trunk-and-branch aspect isn't universal enough. I'm aware of transmission networks that truly treat branches as branches, including separate line numbers for them... but I also think that it's a minor enough occurrence and I think I see a reasonable workaround within the proposal's limits as well. TranslatorPS (talk) 09:07, 16 July 2025 (UTC)

Hello @TranslatorPS:, it's true that trunks and branches are considered in some models. I would have written it's not relevant from OSM perspective since the knowledge defining the branch and the trunk isn't public nor verifiable and the circuit topology may confuse us. Towers numbers and references may be a valid input but won't always solve unknown parts. We would better considering sections in all situations and maybe defining some supplementary tagging (why not supplementary roles for circuit relation) to precise trunk and branch in another proposal. Fanfouer (talk) 14:11, 16 July 2025 (UTC)