Talk:Power lines
Allgemein
Die Änderungen zu dem aktuellem Schema sind ja relativ gering. Unter der Voraussetzung, dass man ein möglichst einheitliches Tagging erzielen will, muss man aus meiner Sicht deutlich mehr ins Detail gehen und auch Spezialfälle (z. B. Hybrid-Maste und -Leitungen für Bahnstrom) abdecken Adjuva 00:16, 7 May 2009 (UTC)
Power tags
Ein eigenes Tag für Erdkabel halte ich auch für sinnvoll. Allerdings sollte man es aus meiner Sicht power=underground_cable nennen, damit wirklich eindeutig ist, was gemeint ist. Das Tag cables=* ist leider extrem ungünstig gewählt. Es könnte falsche Assoziationen erzeugen und deswegen sollte man sich deutlich davon absetzen. Adjuva 00:16, 7 May 2009 (UTC)
Das Tag power=transformator ist sicher sinnvoll, damit man Umspannwerke im Detail abbilden kann. Im Nordosten gibt es mindestens einen Mapper, der das mit Begeisterung macht. Adjuva 00:16, 7 May 2009 (UTC)
Eine genaue Definition für power=station und power=sub_station ist auch aus meiner Sicht notwendig. Außerdem wäre eine eigens Tag für Trafostationen notwendig, um die vielen Sub-Stations einzudämmen. Mir schwebt da was in diese Richtung vor:
Es ist ein power=station, wenn eine der folgen Eigenschaften zutrifft:
- Umspannung von Höchstspannung zu Höchstspannung
- Umspannung von Höchstspannung zu Hochspannung (*)
- Existenz einer Sammelschiene für Höchstspannung, die mindestes drei Stromkreise (Freileitung oder Erdkabel) verbindet
- Existenz einer Sammelschiene für Hochspannung, die mindestes drei Stromkreise (Freileitung oder Erdkabel) verbindet
Es ist ein power=sub_station, wenn eine der folgen Eigenschaften zutrifft:
- Umspannung von Hochspannung zu Mittelspannung
(*) könnte man auch weglassen, Dann wäre ein vereinfachtes Umspannwerk mit zwei 380-kV-Stromkreisen, einem 380/110-kV-Trafo und einigen 110/20-kV-Trafos auch ein power=sub_station.
Mit einer Sammelschiene für mindestens drei Stromkreise kann man die Topologie des Netzes deutlich Ändern und deswegen ist das für mich deutlich mehr als reine Umspannung zur Mittelspannung.
Es ist ein power=subsub_station, wenn eine der folgen Eigenschaften zutrifft:
- Umspannung von Mittelspannung zu Niederspannung
Adjuva 00:16, 7 May 2009 (UTC)
I think there shouldn't be a difference between a power=station and a power=sub_station. The history of the word "substation" started while the power grid was only starting to develop in the world. A city would have a power station (generator), and a substation that turned the voltage down for the city. That's why it's a substation of its main power station.
Now that we have complicated power grids, the "sub" part of the word has no meaning. It's there for historic reasons. That's why I think there is no good reason to invent a new meaning for substations. They are the same as stations. Janko 15:20, 17 January 2013 (UTC)
Andere Tags
Bei ref=* und name=* kannst Du Dich nicht zwischen Leitungen und Stromkreisen entscheiden bzw. wirfst Sie einfach in einen Topf. Aus meiner Sicht ist da ein Riesenunterschied. Die Stromkreise sind der Kern des Stromnetzes und sollten im Blickpunkt stehen. Leitungen sind willkürliche Bündelungen von Stromkreisen. Aus meiner Sicht gehören die Stromkreisnamen (und die Spannung) nach name=* und Mast- und Leitungsnamen nach ref=*. Mit dem Leitungs-Begriff, wie er hier im Projekt benutzt wird, habe ich ein Problem, wie ich es im RWE-Artikel angedeutet habe. Bei den RWE-Leitungen hier in der Gegend wechseln die Stromkreise ständig die Leitung und woanders dürfte das auch so sein. Da aber noch niemand z. B. für E.ON genau beschreiben hat, was genau an den Masten steht, kann ich das Tagging leider nicht nachvollziehen. Adjuva 00:16, 7 May 2009 (UTC)
Das Tag source=* sollte differenziert werden. Wenn bestimmte Eigenschaften nicht direkt beobachtet wurden (eine GPS-Position läuft auch unter 'survey') sollte z. B. über source:ref=estimated eine abweichende Quelle angegeben werden können. Adjuva 00:16, 7 May 2009 (UTC)
Line to cable
I've used in some places on a power=pole the tag pole=air_to_ground. Would extend to tower=air_to_ground, if needed? If there's a connected power=cable on the same node, it's obvious... but in my experience they're quite impossible to survey. Alv 21:22, 30 May 2010 (UTC)
- Thanks for the idea. I will use it and it could be discussed. There was builed a new underground cable near my home. All I had to do was following the open space in street. Of course building this toke several weeks. So I had to visit this more than one times. But I was able to see where they have diggered. Some cables and nearly every (underground) pipeline is marked in Germany by a small sign on the side of the street. I was also able to track an cable which put under earth two years ago. Over a distance of 1589 m there were 17 signs telling me where the cable is. This way
This way represent the cable. --Bahnpirat 20:43, 2 June 2010 (UTC)
- I've surveyd lots of other pipelines, too, but here the underground power cables aren't, apparently, marked in any way. Alv 06:20, 3 June 2010 (UTC)
- There was a discussion about using some of riser=yes, riser:power=yes, riser=power this December on the osm-talk mailing list. Seems better, as it would leave the pole=* for describing the physical structure, i.e. one column vs. "A"-shape vs. others. Alv 12:24, 29 December 2011 (UTC)
route=power
Although I recognize the modelling need for relations describing the different connections on different power circuits on shared towers, I don't think they should be type=route+route=power. All other routes, afaik, have physical objects traversing them. Can somebody come up with other use cases for relations in the power transfer systems? Then it could be something like type=power+power=connection, but native speakers might come up with a more fitting term. Alv 12:50, 23 May 2011 (BST)
Power lines are not routes!
I don't like this tagging: type=route+route=power. Please don't confuse travelling routes (roads, transport routes, hiking routes) and configurations of power lines, and please don't mix one into another. I recommend to use the other type for the powerline relations, namely type=power_circuit. When we'll develop tagging of power lines well, the relation will include supporting structures (towers and poles), points of welding and so on. The relation will (and already is) essentialy differ from a typical route relation.
- Agree about 'routes'. However, I would prefer to use type=power + power=circuit. Then all power related relations can have a common name space (such as "power=substation" or "power=plant" relations). The roles of members could be 'segment' (for line/cable segments), 'terminal' (for substations), 'line_tap' (for tee points = "points of welding"??). I see absolutely no reason to include towers or poles in the relation. That would lead to huge unmanageble relations with no benefits (you can directly retrieve the towers from the nodes of the line segment members). --polderrunner (talk) 15:10, 3 February 2013 (UTC)
- Actually, it might benefit to add tower to the relation where several lines share the same tower. That wouldn't add much hazzle for the maintenance of the data, and could add additional information, such as level of the various lines, and whether or not they tee on the same tower. I agree that putting _ALL_ towers into the relation is pointless, but sometimes additional information can be derived that way. I have not thought about how to do it, and have not bothered to search for examples. --Skippern (talk) 16:18, 3 February 2013 (UTC)
- Sometimes one tower has different reference numbering for each of the circuits that it supports. This is the case and reason to include a tower in the circuit's relation or even make a special relation for a circuit's tower in order to put the ref into such relation (if we had possibility to assign a tag for relation member, see next API proposal if would make life easier). --Surly (talk) 18:43, 3 February 2013 (UTC)
- I'm still not convinced that it is needed. In northern Europe towers always have a single reference number. The individual circuits may be indicated in different ways, e.g. using coloured balls in the tower. How would you relate the different reference numbers to the circuit of the relation? You can only add the complete tower as a member, not individual tags. --polderrunner (talk) 19:46, 3 February 2013 (UTC)
- I'm torn between the data size and the amount of information it will bring if we add towers to relations. The usefulness is as usual irrelevant because if we don't manage to find use cases, someone would.
- When routing for power was introduced, I think mappers would had copied a well known model like road routing. If someone has a better tag for that I'm not against using it. The most important is to model correctly circuits among whole power grids. Fanfouer (talk) 21:58, 3 February 2013 (UTC)
- I'm still not convinced that it is needed. In northern Europe towers always have a single reference number. The individual circuits may be indicated in different ways, e.g. using coloured balls in the tower. How would you relate the different reference numbers to the circuit of the relation? You can only add the complete tower as a member, not individual tags. --polderrunner (talk) 19:46, 3 February 2013 (UTC)
- Sometimes one tower has different reference numbering for each of the circuits that it supports. This is the case and reason to include a tower in the circuit's relation or even make a special relation for a circuit's tower in order to put the ref into such relation (if we had possibility to assign a tag for relation member, see next API proposal if would make life easier). --Surly (talk) 18:43, 3 February 2013 (UTC)
- Polderrunner, are you sure that such two-level tagging will be better? In any case I don't argue against your variant. I strongly argue against using of type=route in the circuit's relations. And I already have thought about tagging of segments and so on. You and I have similar thoughts. --Surly (talk) 18:43, 3 February 2013 (UTC)
- Well, one advantage is that you can retrieve any power related objects just by looking for "power=*". That already works very well for ways and nodes and it would be preferable to also be able to retrieve relations using a simple query. --polderrunner (talk) 19:46, 3 February 2013 (UTC)
- Good job surely :)
- Would you mind if I move it to the Power transmission refinement proposal? Or maybe we can create a dedicated proposal for power routing? We would have dedicated space to document each proposition of that kind. Taking the best from the
Bahnpirat (on osm, edits, contrib, heatmap, chngset com.) pov would be great too. - I'm ok with your point of view but I think there's room for improve tagging words like ref or power=circuit_segment.
- Do the specialized relation power=circuit_segment is mandatory? Can't we directly add all ways to a single power=circuit relation? Fanfouer (talk) 17:09, 10 March 2013 (UTC)
- > Do the specialized relation power=circuit_segment is mandatory?
- Of course circuit_segment is optional. It is useful when a line splits into multiple towers. Introducing circuit_segment we can gather circuit relation members into a sequentional structure without parallel routings. Sometimes it can be useful. Can't we directly add all ways to a single power=circuit relation? -- I think, we can. But if we can make mapping more structural, more strict and more detailed -- why not?
- If you believe that power routing need a dedicated proposal, than feel free to move this chapter into a proposal's page.
- -- Surly (talk) 08:23, 11 March 2013 (UTC)
- I share the concern about power=circuit_segment. It is making the scheme unnecessary complicated just to solve a minor problem (think of the poor data consumers having to evaluate nested relations). My pragmatic approach would be to just include one of the three line segments as member in order to get a sequential line string. Maybe not the most 'pure' way of doing it but would simplify things. --polderrunner (talk) 21:54, 11 March 2013 (UTC)
- I disagree. Routing segments should be sequential, it will simplify processing and ensures that there is no rings in a linear route. That is why we accept splitting of public transport routes and introduce
route_master relation. If we don't fear to embed route relations into route_master relation, I see no reason to fear embedding a circuit_segment relation into a circuit relation. --Surly (talk) 16:11, 12 March 2013 (UTC)
- I'm wondering what kind of additional information it would be bring to us. Can't we add all ways to the same circuit relation? I'm aware that we won't be able to distinguish phases since there's no tags on relation members but is it useful in regard of apparent complexity?
- I began to build a power routing proposal and I'll move the content of this key point there by the end of this week. Fanfouer (talk) 22:35, 12 March 2013 (UTC)
- I disagree. Routing segments should be sequential, it will simplify processing and ensures that there is no rings in a linear route. That is why we accept splitting of public transport routes and introduce
- I share the concern about power=circuit_segment. It is making the scheme unnecessary complicated just to solve a minor problem (think of the poor data consumers having to evaluate nested relations). My pragmatic approach would be to just include one of the three line segments as member in order to get a sequential line string. Maybe not the most 'pure' way of doing it but would simplify things. --polderrunner (talk) 21:54, 11 March 2013 (UTC)
- Well, one advantage is that you can retrieve any power related objects just by looking for "power=*". That already works very well for ways and nodes and it would be preferable to also be able to retrieve relations using a simple query. --polderrunner (talk) 19:46, 3 February 2013 (UTC)
- Actually, it might benefit to add tower to the relation where several lines share the same tower. That wouldn't add much hazzle for the maintenance of the data, and could add additional information, such as level of the various lines, and whether or not they tee on the same tower. I agree that putting _ALL_ towers into the relation is pointless, but sometimes additional information can be derived that way. I have not thought about how to do it, and have not bothered to search for examples. --Skippern (talk) 16:18, 3 February 2013 (UTC)
Power stations
I've splited content of this page concerning power substations to a new page Power_substations Discussion about it moves too :) Fanfouer 00:57, 21 January 2013 (UTC)
Telephone lines
Please somebody create Telephone lines. Jidanni (talk) 07:48, 19 April 2013 (UTC)
- Feel free to create it yourself if you want. I don't see any objection to do so. Fanfouer (talk) 10:53, 19 April 2013 (UTC)
- I wouldn't know what to say. All I know is if OSM (not me!) doesn't come up with a complete telephone line and pole scheme, then I will just mark them as electric lines, because there is electricity in them, unless they are optical. Jidanni (talk) 18:22, 19 April 2013 (UTC)
- Please don't do that. They are not power lines. The problem is that telephone lines are completely undergrounded in most parts of Europe and many other parts of the world. And since the majority of osm users live in such areas few people have had any need to create tags for overground telephone lines. The situation may be different in other parts of the world (I don't know where you live). You could use telephone=line or similar but don't expect it to get rendered anytime soon. Even an approved proposal may take a long time to get supported. --polderrunner (talk) 19:21, 19 April 2013 (UTC)
- A phone line is not a power line, it must not be tagged wrongly as such. Taginfo tells us that today the following tags have been used (sorted by count)
- phone=line 418 way
- phone=pole 48 uses
- aerial_line=telephone 45 ways
- phone=tower 35
- telephone=pole 20
- communication:Telephone=Hand Phone 16 ways
- telephone=minor_line 6
- telephone=line 2
- man_made=telephone_exchange 120 uses
- Therefore I would say that the best answer at the moment is to use phone=line for the ways, even if others use the same key for recording the phone numbers of amenities. Then file a ticket at trac to get them rendered. (At the moment the style sheets have been quite stagnant, because updating them had become too much work even for a single change. Those with the knowledge are coming up with a solution to make their maintenance easier. That is to say, it can still take some time to get anything changed; it's faster to set up your own tiles with the phone lines rendered.) Alv (talk) 14:01, 20 April 2013 (UTC)
- Wouldn't a well planned (official) solution (and cleanup) be better? Here's some phone lines and poles if you need them: http://jidanni.org/location/dj.kmz . I'll sit back and let the pros take care of this. Better for everybody in the long run. Jidanni (talk) 17:14, 20 April 2013 (UTC)
- I wouldn't know what to say. All I know is if OSM (not me!) doesn't come up with a complete telephone line and pole scheme, then I will just mark them as electric lines, because there is electricity in them, unless they are optical. Jidanni (talk) 18:22, 19 April 2013 (UTC)
Draw one way for all circuits connected to one power tower or pole.
Draw one way for all circuits connected to one power tower or pole.
Seems like a simplification that one will regret years from now...
Just like bus lines: use one same colored line on the map for all routes?
Jidanni (talk) 18:49, 26 September 2022 (UTC)
- Routes should be described with relations, as proposed in Proposed_features/Power_routing_proposal. We actually and already regret to have many lines with routes attributes (frequencies, references, operating voltages - opposite of design voltage) that will have to be moved once routing proposal reviewed.
- Even without routes, it is possible to draw parallel lines with different colours according to voltage. See OpenInfraMap here for instance Fanfouer (talk) 19:00, 26 September 2022 (UTC)