Yes they are. But adding a way as a relation member won’t edit them, right?
This proposal won’t impact the given power line as there is no frequency on it, particularly.
So it can be involved in circuits relations without changing its tagging.
Survey may show it is incomplete nearby of Lincoln Main, but it’s not on proposal purpose, it’s usual power line completeness depending on survey.
I have listing at User:Mateusz Konieczny/power relation creators - OpenStreetMap Wiki
But it impacts them, making editing of such objects far more annoying. (this does not invalidate it by itself, but it definitely impacts them)
I can make a Wiki page if that helps 
But seriously, while I have occasionally claimed in other discussions that an “average person” should be able to verify things, I have not done that here. I have instead said that only very few people will be able to survey this information, and that therefore if there is to be any significant amount of coverage, there will be a lot of totally un-verified importing going on.
At this point I don’t care much about exactly how many people with what equipment can verify the data, as long as someone does. But it appears to me that a fig-leaf case of “well this could theoretically be verifiable” is being built that will serve as a reason for importing data that is essentially a foreign object in OSM because only a handful of people on the planet will dare to touch them.
Hello,
True for impact in that way.
Different times, different hassle: currently, maintaining redundant tagging (the proposal has got a whole table about that) is yet annoying. Like for hiking, adding relations is also an opportunity to care more efficiently about what is actually edited.
It’s annoying because of UX, not because of data model and the first should be discussed with editors.
I may mistake what do you mean by “this information”. I assume it’s about circuit relations.
Do you have any evidence of import regarding the existing 30k relations?
Had you tried yourself to add one and fall back to import anything following this experience?
I’m dealing upside with pure survey about @SomeoneElse example.
for example edit splitting power line included in relation will become listed here
in the same way as someone who split road in public transport relation will become its last editor
while you are right that in theory way splits would create new versions, these aren’t expected along power lines, it is not the same situation as a road split, because there are many reasons for road splits and few or none for power line splits.
The more a given type of objects is reused in a structured way (as opposed to just applying colour on paper where there are objects), the more the edition of these objects requires some care. I would not characterize that as annoying; not any more than, say, looking out for other traffic when driving on a road.
What I perceive in some arguments is a kind of chicken and egg situation, or a notion of return on investment actually: is this going to take off and succeed or is this all for nothing in the long run? Maybe OSM needs some guidelines for innovation so that such decisions can be taken based on data? Maybe actually we don’t need those guidelines because whatever innovations don’t fly just perish in the long run.
In such cases I tend to refer to https://wiki.openstreetmap.org/wiki/Verifiability.
it seems questionable at least with regard to the bold sentence: “
we map a lot of things that happen with regular frequency, “every time” suggests permanence that is not required. We do not expect to find a winter road in summer, to give an obvious example.
@Jarek Just to provide a little bit more context and lessons learned from mapping:
OhMyGrid (https://ohmygrid.org/) has now mapped 118,934 power towers, primarily using Osmose and addressing the ‘Unfinished Transmission Line’ issue. Although external open data is helpful, it is actually not nearly as important as we thought at the beginning of the project.
Osmose and MapCSS were crucial. We have used this experience to optimise our tools and training courses, which we now offer free of charge. You are very welcome to find out about the different methods we have developed (Tools and Strategies 🛠️ - OhMyGrid).
@woodpeck
Based on this experience, we also discovered that, contrary to my expectations, many transmission lines are clearly visible in Bing, Mapbox and ESRI satellite images, particularly for large installations with high voltages. Here, the routing of individual lines can be traced quite well. In short, it is often possible to verify routing using satellite data. I admit that this requires some training, but it is possible. Here one example from Kenya.
Now that we have developed most of our tools, our initiative will mainly focus on training and empowering others, especially local communities, to verify and map transmission lines.
The question of permanence does not apply to the discussion we are having here; nobody has (yet?) claimed that power circuitry might be non-permanent and therefore only observable at certain times.
I understand that @dieterdreist challenges the general relevance/maturity of the verifiability principle on the basis that it contains logical weaknesses. Which, admittedly, is not a straightforward approach given that the main and most frequent concern regarding verifiability is about what will never be verifiable on the ground but from authorized sources.
I have mapped a ton of power towers and lines myself, and I think this information is definitely valuable in OSM, and easy to map for everyone, even from aerial imagery. The presence of power towers and transmission lines is an important topic that directly influences the lives of many. There is no doubt that this information should have a place in OSM.
But correct me if I am wrong - the proposal being discussed here is not about “should we map power towers and power lines”. It is about whether we should try to determine the actual topology of the power network, like what is connected to what, including super technical details like the impedance of a section of the network. Even the basic topology is something that you would have to be very lucky to be able to determine from aerial imagery; but some of the details that this proposal wants to elevate to accepted mapping practice seem to me to be un-mappable without having access to privileged information (or importing stuff).
There is already today a situation in Europe - the latest case we had to deal with was from Germany - where operators are concerned with the level of detail of power infrastructure available in OSM. Our standard reply when they ask us to remove “critical infrastructure” is “we have surveyed this ourselves, so we have a right to publish it, go away”. I am very interested to keeping this alive. The more hardly-surveyable stuff we have in our data, the less credible the “we have surveyed this” mantra becomes. For example there’s quite a bit of underground power infrastructure in Berlin in OSM that is of very dubious origin and that might have to be removed at some point, especially because it is detailed to a point where it becomes hard to argue “well I saw they were digging a hole and putting in some cables so I guessed”.
As long as the data we add is properly verifiable (and as long as it is credible to survey the data with the number of people we have), we have a clean bill of health when it comes to questions about our data sources. I’d like to keep it that way, but especially in the domain of power infrastructure mapping, a lot of stuff has already crept into OSM that is of questionable origin, and if push comes to shove might have to be removed again one day.
People might find me narrow-minded for insisting on verifiability, but it gives us the security that this is clean data we can keep, as opposed to data that has been added from shady sources that might one day have to be removed.
Please note that verifiability on the ground is not an insurance against legal issues. Here we have cases were it is forbidden by law to disseminate your ground observations, whether for secrecy or for intellectual property concerns.
The legal framework in France actually provides some kind of intellectual comfort: if a topic is covered by a legal secret of any kind it cannot be disseminated at all, if not then all public organizations must disseminate any data and documents that they have. This gives us solid grounds, not directly related to sources, for determining if a given subject can reasonably be treated in OSM.
Note I completely second this. It’s a really important asset we should preserve.
I don’t intend to weaken it.
Nevertheless, this proposal isn’t an import proposal. Voters aren’t polled about the legitimacy to use or not whether data source in particular. They should comply with OSM community guidelines at all time, particularly when they choose a data source.
We are questioning the consistency of tagging, occasionally the way we model reality in digital material with the help of our ontology.
Once agreed on the proper ontology to use (not the single one but a rather consistent and versatile one, that could be improved in the future), time will come to agree or not about relevant (or not) import if necessary.
That’s two different debates we should not mix. Opposing tagging in voting won’t prevent anyone to use discouraged/forbidden data sources to actually add the information if they want to. We would better organize knowledge to ease inspection.
As you said, consideration may change over time and we may remove something that was perfectly acceptable in the past.
How anyone is supposed to contribute, maintain and maybe filter and remove something that is poorly described?
it expresses / implies / supports imports
I guess that people react poorly to that as we had repeated cases of proposals technically not deprecating something, technically not doing something then people immediately proceeding “well, proposal de facto deprecated XYZ”
Good to know this document is partly blamed on something it hadn’t introduced.
This vote won’t allow anyone to suddenly import anything without further and necessary discussion.
I would be used in “approved proposal told us that such imports are excellent idea and should be done” way.
And yes, there is not an obvious way to avoid it, given that primary way of getting such data is importing it. Not mentioning imports in proposal would not help much.
Does adding “This proposal is not an import encouragement at first and every attempt should be discussed in accordance of imports guidelines” would lower the risk you mention?
At the risk of inaccurately putting words into people’s mouths, my perception is that the concern is about data that can only be feasibly added via import. An import can fulfill import guidelines, have a valid license, be discussed, etc. But people who don’t want the import can object to the tagging proposal in the first place if their perception is that the tagging will highly likely trigger import proposals.
To lower the opposition to the tagging proposal from anti-import people, you could consider removing parts of the proposal that are realistically only obtainable via open data and not survey, like impedance.
I appreciate the intent to find explanation and it may be right.
If accurate, this raises important questions and relates to innovation policy that @StC mention before.
As we already have such keys in OSM, like addr:postcode, that couldn’t be verified on ground for most addresses, why should we refrain from defining keys and then discuss imports in dedicated context as of now?
I’m not trying to compare post codes and impedance values, but both are subject to be obtained from open data or be asked for to knowledgeable people in some way.
By the way, not approving keys won’t prevent to document them as proposed in the wiki and other people to propose imports in their area in the future.
The only way to prevent actual harm to OSM is to regulate imports and improve traceability, not regulating tagging documentation.
