Proposal talk:Power transmission refinement

minor lines and voltage levels

Resolved: Consistent with proposal content Fanfouer (talk) 18:29, 11 September 2013 (UTC)

as named voltage levels for minor lines, the possible values should be medium and low. I just copy my statements and expand them:

• The following levels could be possible: low: up to 1000 V, medium: 1000 V - 50000 V (or 60000 or 80000 - I don't know where there could be the upper level according to international used levels - in germany the upper level could even be something like 30000 V, because the most used levels are 20000 V, 10000 V and 15000 V) , high: more than 100000 V (or whatever the upper level of medium will be) (Schusch 12:12, 13 June 2011 (BST)
• it's quite easy to see if the voltage level is low, medium or high - depending on the length of the insulator (at least in germany). But especially for medium voltage, it's not easy to know, if the medium voltage is 10, 15, 20 or maybe 30 kV. That's what I wanted to address with these levels. (Schusch 22:22, 21 June 2011)

Up to now we tend to tag medium voltage lines as "minor_line". These should by no means be changed into voltage=low but to voltage=medium. I would suggest only voltages lower than 1000 V should be tagged as low (see above). I'm going to change this small detail on the page. Greetings -- Schusch 08:20, 19 July 2011 (BST)

Difference between cable and line

Resolved: It's not a problem anymore : power=cable will still be available in power template, according to the proposal 2nd version. Fanfouer (talk) 21:50, 4 November 2013 (UTC)

I think there's some mess around the difference which power=cable and power=line try to introduce. At high and medium voltage, underground AC lines are built just exactly the same as aerial lines : 1 conductor for each live. Except these conductors are isolated. So it's not just a cable but a line. The need of isolation is only due to undeground location, given by location=underground. There's no need to emphasise this fact at all, don't you? So power=line + location=undergound seems to be smarter than power=cable + location=undergound

In the meantime, power=cable would allow us to map distinguished live wires, especially in power substations where, sometimes, lives are taking different path to get on busbars. This is according of what is described there : http://wiki.openstreetmap.org/wiki/Power_lines#inside_power_stations

Third and finally, in regard of cables=X tag, which indicates how many lives you have on each power circuit. Continental lines are AC-lines with 3 lives according to Westinghouse preconisations and patents. Generally, this information musn't be defined for each line but for the region where they're located in. There're some exceptions like HDVC lines which are composed of only two cables (not only one gentlemen), no lives anymore, because of DC transit.

Can't we use tags like power:line=HDVC instead of always showing the number of cables which will be the same 99% of times?

On the oher side, specifiying the number of conductors per live is useful because it's a property of line and there's no commun rule for it.

Regards. -- Fanfouer

To common people underground cables look pretty much totally different from a typical power=line - normal people can't even see the underground cables, even if power transmission pros and enthusiasts might find them. That already makes it a different "thing", hence a different tag has been used. Alv 10:42, 10 January 2013 (UTC)

I agree with you : it's a different thing and that's why we are using location=underground.

With this tag, the render can be totally different or undergound lines could even be hidden on standart maps.

I took some photos in the street. Something that everone could see : http://www.infos-reseaux.com/photos/album/61-genie-civil-souterrain There're as many conductors as an aerial line.

Moreover, cables are part of a line and using power=cable instead of power=line is confusing because we don't know if we have the whole line or only a few components. Fanfouer

You seem fixated on a power engineer viewpoint and power engineering terms. OSM is not, in the sense that a power=cable in osm means a "something to carry current and buried underground", and not "what power engineers would call a cable". power=line already implies that it looks somewhat like the typical overhead line on big pylons - then negating that with a secondary tag is better avoided (as in "it's a big power line on pylons, ... except that it's not"). If you want to know what components are underground, you can help by instructing casual mappers how to recognize such details, and make up the tags needed to describe and to classify any underground power transmission lines. Alv 22:28, 12 January 2013 (UTC)

I'm not (yet) a power engineer. I think that OSM should model the bare reality and call things just like what they are. I don't understand why you want to make a difference where there's not and in the main time use a separate tag to put the business underground. It's all about vocabulary.

There are already over 180 000 ways in OSM database with power=line already, so data consumers (there is no "the renderer", but many individually run consumers, mind you) have become accustomed to presenting them always as if they were big overhead lines. Suddenly tagging underground stuff with the same tag would break things. Alv 16:01, 15 January 2013 (UTC)

If users want a stable data-set, they can download an extract of planet. OSM won't be stopped to wait for consumer adaptations each time tagging scheme will be modified. Fanfouer 19:55, 15 January 2013 (UTC)

Data consumers should be allowed to expect that the meanings of tags don't change overnight, even when the data is updated. Consumers trust that the data is improved on each update, and that they don't have to be on a lookout for drastic changes. Everybody has set up their map styles with some (sometimes unwritten) expectations of what each tag represents, but those implied meanings have produced an usable map. If mappers are then instructed to use the same old tags for different things, established uses get worse data. If they were to start using a brand new tag only, the established users would just miss and ignore the new data, until they found it worthwile to amend their system. That's why the recommendation has been from the very start to document your new tags as early as possible, so that others wouldn't unknowingly use it for something different. All "changes" to date have not reused the old tag for something different, but have moved from one/several tags to several other, new tags, gradually over a long time. Tags are cheap, don't try to redefine, but you can always come up with a new one. Alv (talk) 23:07, 11 February 2013 (UTC)

It's the same as roads "Oh, you're not a road engineer, you can't understand properly what matters", but in OSM, roads are fully described with many details, don't you?

You made a strong point for the negation of location=underground if you want to obtain only plain aerial lines.

Let's try to find a compromise. As I said before power=cable could be useful to map single live cables instead of whole lines (especially in power stations). I don't see any values to use instead, ideas?

Although power=underground_cable is suggest to deprecation, we would use power=underground_line or something like this. But, now, why should we use location=underground? Fanfouer

I do have a degree as a power engineer and I agree with Alv that the current practice of using power=cable and power=line to represent insulated (underground) cables and aerial power lines respectively is sound! These two tags are very easy to understand by OSM mappers who are not experts in power transmission. They represent two very different technologies only sharing the fact that they transmit electric power at high voltage. I simply don't understand why you want to reserve power=cable for internal details of a substation, you could simply use power=line (or power=cable) + cables=1 if you want to map every single wire or rail within a substation. That wouldn't require a major redefinition of the well-established power=line and power=cable tags unlike your proposal. The average mapper and data consumer only care about whether there is a power line visible in the landscape. If "power=line" then draw a black line!

Furthermore you claim that high voltage underground cables are normally single conductor. As far as I know it is now common to use three-phase cables at voltages up to 150 kV. This is actually a problem if you want to model the power network with the correct number of circuits. First of all you don't generally know the number of physical cables in an underground connection (they could be single-phase or three-phase cables and you won't know unless you have inside information or happened to observe the digging work). To solve this problem I'm preparing a wiki page for a new circuits=* tag to extend the existing power tagging scheme. This tag is backward compatible and won't redefine anything existing. It is mainly intended for underground cables where the cables=* tag is absent or ambiguous. --polderrunner 20:44, 13 January 2013 (U

The main reason of my proposal is precisely because lines are composed of cables. Underground and aerial parts of the same line are sharing pretty same conductors to transmit lives between two power stations. http://www.agri85.fr/bibliotheque_image/FDSEA/20110204_20110204_ligne_electrique.jpg

I still don't understand why we had to say it's a cable underground and a line outside while it's the same functional thing. Why are you saying it's two very different technologies? Just because of insulation? Aerial lines could travel through gas too (is this a really different thing?) but no one seems to have noticed that.

In regard of the number of conductors, I understand it's all about power. In France, lines are conductor-separated cables from 20kV, even underground ones.

To know the number of cables of an underground line after the digging works ended, you can go each side of the line to see where it comes out. Only if the substations are not in a building nevertheless. http://www.rte-france.com/uploads/media/images/m-dia-principal455/lignesouter-455.jpg

Concerning the circuits=* tag, this information can be given by the cables=3;6;... like aerial lines! It's ambiguous just because we use power=cable to document underground lines. power=line + cables=* + location=underground sounds clearer than power=cable + circuits=* + location=underground ("oh we have a cable... no 3 cables actually which are underground". "-err 1 or 3 I don't understand?"). Moreover, circuits are fully documented by relations using ways to create routes between substations.

To finish, I can't use standard power=line inside substations because many times it's more schematics than mapping as for managing to represent the substation clearly. You can't put power=tower or other pole on each node and it creates structural errors on Osmose. Semantically and topologically, we can't represent something as a power line while it's just a part of a power line.

It would be great to produce such graphics and only with OSM data -> http://www.rte-france.com/uploads/Mediatheque_medias/conduite_reseau/dispatching_regionaux/sud_est/PH573-062.jpg Fanfouer

Hello! Most of what we talking about here was produced by me some years ago. In these days a power line was power=line and not more. Most times power=tower were missing, like you can still find it in USA. Possible I made some errors in these days and may be the time has come to question the standard, if it's still up to our needs. But first we need to find the same language. --Bahnpirat 21:18, 15 January 2013 (UTC)

Hello Bahnpirat, nice to see you there. Fanfouer 21:52, 15 January 2013 (UTC)

Having an engineer is good to prevent us from errors. But OSM need to be accessible for the untrained or have at least only a low barrier to join. cables=6 is one example. Of course circuits=2 (for 2x three phase line) seems more correct. But most people only see 7 lives (is that the correct term?). 3 right, 3 left, and one on top (lightning wire), sometimes number 8 between (fiber for IT). That's why I invented cables=*". Not because it's perfect, but easy to understand for the untrained user without knowledge about electric grid. --Bahnpirat 21:18, 15 January 2013 (UTC)

You're right, power grid mapping is certainly more technical than it seems. Nevertheless, if people don't really know what they're mapping, don't upload is still an option.

Letting them using power=line for any kind of power line will allow them to map faster because they won't get into details. Someone more confident will be able to put some extra tags to improve description.

For me, lives refers to the Lx symbol (L1, L2, L3 on a 3-phases circuit). Fanfouer 21:52, 15 January 2013 (UTC)

Problem is people think of their own country first and not further. Germany, Austria, and Swizerland share a power grid to power their railways. This grid operates with 1-phase / 16,7 Hertz AC. On a power tower there are two wires/lives per circuite. So it's not always three! Underground power lines can have three seperate lives or one. A cable can also be overground! There can be different operators on the same tower. --Bahnpirat 21:18, 15 January 2013 (UTC)

Yes, I admit this part of my proposal isn't the best thing to do. Even with 3 lives national grid, we can find situations where there are different numbers of lives in circuits. cables=*, circuits=* are relevant at world scale. Fanfouer 21:52, 15 January 2013 (UTC)

What I trying to say is, keep it easy to use. Not every case have to be defined exactly. But everthing should be possible. I'm against mapping every lives seperate. Would you do this for overhead power lines? Producing such power grid pictures (http://www.rte-france.com/uploads/Mediatheque_medias/conduite_reseau/dispatching_regionaux/sud_est/PH573-062.jpg) is manually work, because it is not a geographic, but a schematic map! A renderer can draw three lines for each circiute. But this should not be drawn in the OSM-DB. My opinion. --Bahnpirat 21:18, 15 January 2013 (UTC)

No, I'm against mapping each live, circuit, cable separately. But if we use power=cable, it's cables and not lines which are supposed to be mapped, don't you?

Regarding of my schematic map, there are some algorithms to draw such things by knowing nodes and paths. I don't need geographic information but the topological data and I aim to get that from OSM. That's why mapping circuits by relation and inside substation stuff would be very useful for me and for all persons who want to get that kind of data. Fanfouer 21:52, 15 January 2013 (UTC)

I find the suggestion to map underground cables with another value (power=cable) inconsistent (for example we don't do it when highways go underground). Current definition of power=line (a way [...] of power cables) is very wide and suits perfectly the needs of casual or power engineer mappers. It is not explicitly written, but as I understand, a power line is a set of one or more cables carrying high voltage. Whether it is running in the air, on the ground, underground, insulated or not... should be stored in other attributes (as we already do for highways). As suggested Fanfouer, if you want to map a single cable in a power station, use tag power=cable. I find this tag very easy to understand and remember. - In addition, the definition does not mention any minimum voltage value. We may not map 110 V or 220 V local networks with power=line. Although, to be consistent with current definition we should... --Oligo 22:59, 17 January 2013 (UTC)

Good point about highways! As mentionned on tagging mailing-list, it's the case for pipelines too : man_made=pipeline Fanfouer 11:04, 18 January 2013 (UTC)

OSM tagging has evolved in different ways in different areas of interest. There is no point, need, or sense in trying to introduce "consistency" between tagging schemes just for the sake of consistency, when their users have different primary needs. Example: for most conventional maps, a road is a road, be it in a tunnel or on level ground; then again, a primary road might look physically identical to a secondary road nearby, and at least it functions just like any other road: cars and other road users travel on a roughly level surface, and they connect their endpoints together. Shouldn't we call everything a connection=road, and use tags like surface, lanes, lit, maxspeed etc., and then "the render can be totally different or narrow dead end alleys could even be hidden on standard maps"? The first point is, that different features are sometimes modelled on the "first tag level" "as the common people see it", and tagging schemes of other features start from the professional and hobbyist viewpoint on how that feature is utilized and modelled. The second point is, that there's more than turn by turn routing (the connect end points bit earlier) to maps, and to the data about roads. For many every day uses of maps a road is also a barrier, or a source of noise and so on, where the difference between the values of the highway tag already have a big impact. Likewise, for most people a power line is "a big linear physical thing on big towers" - both for mappers, and those making their own maps. That is what they are expecting when they come across a way with power=line; a different value is used, when there's a big difference to other kinds of linear power structures.

Most of the time pipelines are underground, so they are very seldom drawn/noticed at all by the data consumers. Were you to give a bunch of osm data for common people to draw a map from, they would skip the pipelines as "invisible in the nature"; Then those, who do want to see them on Their map, can be expected to look up how they're tagged, and be tagged with several tags - especially, when using location=* with pipelines was the guideline from the very beginning when somebody started drawing pipelines. Now the proposed method first says "this is big wire on pylons", but then claims with another tag: "no it's not a big wire on pylons, it's actually something you don't see at all".

Especially, when being an "overground big structure" has been the reasonable expectation for so many years already, I'm quite certain that "deprecation" is not going to be respected, nor will the maintainers of the most used map styles amend their style sheets. (There's even a technical point to it with the current toolchain; if the rendering style wants to use a key (here "location") that wasn't imported into the rendering database initially, they have to flush and reimport the whole database on the rendering server with amended settings). Alv (talk) 23:07, 11 February 2013 (UTC)

Like the "common mappers" assertion, I don't understand why power users shouldn't map piplines or something else than power stuff. Consistency is precisely the key which allow an OSM mapper to document many kind of infrastructures with the same way of thinking. Tagging model must be designed to allow people to do things, not to complexify mapping and I think consistency make it simpler.

Secondly, concerning the tool-chain, it would be great to have tools developpers' opinion about the better tagging model to implement. I will send a mail to dev mailing-list to ask for it. Fanfouer (talk) 16:11, 10 March 2013 (UTC)

This discussion should move to page Talk:Tag:power=cable because we are not debating on the proposal. --Oligo 22:59, 17 January 2013 (UTC)

Done. The discussion continues on Talk:Tag:power=cable since this morning. Fanfouer 11:04, 18 January 2013 (UTC)

transition towers

Resolved: Added to proposal. May vary on wich man_made or power is finally choosen for power supports Fanfouer (talk) 18:29, 11 September 2013 (UTC)

The example image shows a transition tower that does not use a fenced area. Fore these cases, I don't see why air _to_ground should be deprecated. and replaced by a substation=transition area. Basstoelpel (talk) 14:18, 1 June 2013 (UTC)

We can consider that such a transition is a particular element of a power network. polderrunner and I think power=substation would be the right tag to group all particular places of that kind.

tower=air_to_ground is only just another tag to map a feature which can be mapped with more effectiveness.

Furthermore, even if there's no fence on the example picture, it's not so easy to access the place between the tower base, don't you ? Fanfouer (talk) 18:58, 1 June 2013 (UTC)

The substation=transition tag is really only intended for fenced areas around cable terminals on the ground. If the terminations happen in the tower itself (no fenced area on the ground) I prefer to use the existing tower=air_to_ground tag. I am going to clarify that in my proposal. --polderrunner (talk) 19:29, 1 June 2013 (UTC)

Ok sorry for misunderstanding polderrunner. If we choose to use a different tag for non fenced facilities, what do you think about tower=transition and pole=transition? It's consistent with substation=transition and more general than "air_to_ground" (So many" air_to_xxxxx" values to introduce instead). Fanfouer (talk) 08:56, 3 June 2013 (UTC)

The tower=transition attribute has already been documented on Tag:power=tower#Tower_type. Thus no need to include this tag in the proposal. --polderrunner (talk) 20:06, 5 November 2013 (UTC)

I saw. But it precisely this proposal which deprecates air_to_ground in favor of tower=transition ("The value 'transition' has been proposed to replace the previously used value 'air_to_ground' which should no longer be used.").

Why did you have add it before the voting ? Fanfouer (talk) 20:53, 5 November 2013 (UTC)

Well, it is now *after* the voting! This attribute tag is replacing the 'air_to_ground' value that has never been voted but just introduced by somebody as an adhoc value. Further, the transition attribute was one of the few things of the proposal that were not objected to by the opposing voters. I had already documented the transition value some time ago as part of defining other tower attributes but without deprecating the former value at that time. Since this is just a minor attribute with limited use and the change doesn't break anything I find it fully acceptable to make the change. As far as I know no applications or renderers so far support this attribute in its old or new version. And none of the editors have the tower=* tag in their presets. --polderrunner (talk) 08:16, 6 November 2013 (UTC)

I mostly agree with you and thank you to take time to document it. Nevertheless two practical problems for me to don't do so :

- I wouldn't fragmenting post-vote cleanup. The proposal will or won't be accepted, but always as a whole set of concepts.

- The first version was rejected. We must work now to edit concepts that didn't get contributors attention and remove some of them, not remove those which can get this proposal accepted :)

No problem with tower=transition => no edition. Fanfouer (talk) 12:31, 7 November 2013 (UTC)

Several circuits share the same tower / circuit specifications

Regarding the circuit specification on the power=line, we need to decide how we can effectively represent all different circuits on only one object. The proposal currently recommend to write the number of circuits sharing the power line by using circuits=*. Other tags like wires=* or cables=* don't actually represent the line but all and each circuit. When several circuits share the same line, we need to put several values separated by ; but what about the order we write them ? The trick is to identify an arbitrary circuit order and keep it for all different tags. But we won't able to implement a consistency check to force users to keep this order, so it's not a great way of thinking. Fanfouer (talk) 13:17, 3 June 2013 (UTC)

level tag

Resolved: Good idea. Fanfouer (talk) 18:29, 11 September 2013 (UTC)

For what do you use level tag on power lines? RM87 20:30, 11 June 2013 (UTC)

Since OSM isn't managing 3D and elevation very well we can use level to distinguish two objects, especially underground.

Overground it would be useful with bridges for instance. Fanfouer (talk) 21:43, 11 June 2013 (UTC)

layer=* is needed when there are two different minor_lines partially sharing some of the poles on some stretch, like in the image. (In the past some suggested not to map these as two ways, but that seems wrong when the other line doesn't touch all the nodes, yet the other line has to touch all of the pole nodes. and their circuits are not directly connected here. The line mounted higher is maybe 10 to 25 kV, and the lower line (probably 400V) has more densely spaced poles because of the street/footway lamps it feeds. A power line way should only touch the pole/tower nodes that the conductors "touch" (via the insulators, naturally). The elevation hardly ever corresponds to a building level, except where the line penetrates the wall of the building it was built to feed. Alv (talk) 22:47, 11 June 2013 (UTC)

You made a very good point here (and a very beautiful drawing :) ).

I'll work on this topic. As for not compromizing power routing over power grids, we should map all segment freed from number of circuits but on the special case you're talking about, it's no matter of circuits but 2 different stacked lines. Fanfouer (talk) 12:35, 12 June 2013 (UTC)

Power=tower on low voltage lines

Resolved: Added to proposal. May vary on wich man_made or power is finally choosen for power supports Fanfouer (talk) 18:29, 11 September 2013 (UTC)

Node power=tower have to be used only with "high voltage lines" Way. Do not use the symbol "tower" in combination with only "low voltage lines" Way! Otherwise at certain Zoom-Levels you see towers on the map without conductors, which does not look very nice!

Mappers should create a model that is consistent with reality. Sometimes reality does not look very nice! Trying to make a map look nicer than reality is not completely honest.

After the data are correct, what you render is a question of preference and it often depends on the purpose of the map. If I want to illustrate the structure of the power grid, I render the lines that have the largest voltage and the greatest number of circuits (cables) on all zoom levels. I render individual towers (or poles) only at higher zoom levels; and if there is an anomaly such as a huge tower with no lines, I definitely want to see that.

If you render a general-purpose map, you want to render the features that are most visible in real life (on various zoom levels). This depends not only on the voltage rating (through the size of the insulators and the spacing between cables) but also on many other factors: the height, width, shape and color of the towers, the lengths of the spans between consecutive towers, the total width of the power corridor (a set of adjacent parallel lines) and the total number of lines/cables/wires. Unfortunately, not all of that information has been systematically mapped. --T99 11:14, 11 October 2012 (BST)

Allow using towers on low voltage lines as in reality these are used on low voltage lines in places where lines cross with wide rivers/railroads/highways. It's also possible to find single towers in low voltage line corners, swampy areas and sometimes in random places (because some engineer just found a reason to use a tower instead of pole) RM87 20:30, 11 June 2013 (UTC)

I agree with you. I'll update proposal consequently to your comment. Fanfouer (talk) 21:44, 11 June 2013 (UTC)

I don't agree because we don't have a clear distinction between what is a pole and a tower and it will lead to incoherent mapping. Is a single mast made of concreete carrying 90 kV lines a pole ? Is this really a tower ? Is this really a pole ? I think we have to stick with pole for low voltage lines and tower for high voltage lines because it's easily verifiable, and then we can refine the tag with design=*, tower/pole:type=*, etc. Plop76 (talk) 08:26, 12 June 2013 (UTC)

IEC defintions are clear : a tower is a multi-sided structure (or commonly 4-sided not to mention) whereas a pole is a single mast made of several material like concrete but metal or wood too. Using power=pole with every low voltage line just because it's easily verifiable is obviously wrong. According to your pictures and definitions, we firstly have big poles and a small tower. Fanfouer (talk) 09:31, 12 June 2013 (UTC)

"comprising a body which is normally four-sided, and cross-arms " is not clear. And the first picture is an example of power=tower in this wiki (design=bipole), and the second picture the main example of power=pole... so it's obvious that you can't say that pole/tower are "pretty well described in the wiki and this proposal is for now consistent with this existing stuff." Plop76 (talk) 09:57, 12 June 2013 (UTC)

The trick is "A tower has more than 1 foot on the ground". Is it clearer ? On the first pic, you just have two independent poles (mapping such a thing in OSM requires 2 independent with power=line + circuits=1 on each). On the second picture, you have a tower with 4 sides. Since nothing justify this particular point of the current definition on the wiki, pages would be updated. I said "pretty well", not "perfectly defined", got it :) ?

Be sure I will update proposal with more clearer stuff to let people understand what a tower really is Fanfouer (talk) 13:11, 12 June 2013 (UTC)

It is clearer but I don't agree with it :) For me, this bipole is a tower and should be mapped with power=tower (because it supports a high voltage line, and because it is huge :D). I don't see the point of having a different "main tag" only because a pole/tower has "1 leg" or is "multi-sided". For that, there are the tags design, height, tower:type, etc. Plop76 (talk) 19:14, 12 June 2013 (UTC)

Your "bipole" is actually 2 distinct poles. Look, there's no link between them. Thus, 2 ways must be added to map. Like [here].

We make the distinguishing between tower and pole because IEC do so. If I introduce one only tag here, other users who like a lot consistency with what already exists would be angry :)

But I keep this in mind. Fanfouer (talk) 22:05, 12 June 2013 (UTC)

Well, it is "my" bipole. I created that tag and I have mapped all existing bipoles (they are found around The Hague where I live). Although they are technically two closely spaced but separate towers I have mapped them as single towers and a single power line. They are designed to be used in pairs (it is about bringing the conductors close to each other to lower the magnetic field). Therefore I consider it more appropriate to map them as a single feature (the two pylons in a pair don't even have separate reference numbers). It also reduces map cluttering. --polderrunner (talk) 22:40, 12 June 2013 (UTC)

Ok for map cluttering, indeed :) Fanfouer (talk) 23:41, 19 June 2013 (UTC)

This "bipole" was not a good example, because my point was not whether to map it with 1 or 2 nodes. My point was that with your definition of poles and towers, this bipole is made of (one or) two poles, whereas I consider it as (one or) two towers. A better example : this pylon. «one foot on the ground» so it's a power=pole ? Plop76 (talk) 08:08, 13 June 2013 (UTC)

Alv (talk) 23:01, 11 June 2013 (UTC)

I'm thinking of another tag combination : power=pylon + pylon=tower or pylon=pole but the distinguishing between tower or pole will remain the the same problem. However, even if it not consistent with what already exists, it will be simpler to render. Fanfouer (talk) 23:41, 19 June 2013 (UTC)

Bad idea considering that power=tower and power=pole are some of the most frequent tags in OSM. I can't see any benefits of replacing those tags with a new one with subtags to do the same job as the current tags. What is needed is to clarify that 'tower' means a support for a power=line of 50kV or more (and not what it actually looks like, we have separate tags for that) and a 'pole' is a support for a minor power line (even if it looks like a braced tower). I am willing to accept the use of power=tower for minor lines when such supports are of significant size compared to normal poles (e.g. for river crossings or because they are designed for a higher voltage than currently used). --polderrunner (talk) 20:47, 20 June 2013 (UTC)

Ok, we won't merge tower and pole. But the problem is we can't be compliant to IEC definitions and dealing with rendering problems on the same time. The most important is use tags accordingly to what definitions are saying. Otherwise we are about to postpone decisions to future, as we made for power=substation. Even in France I see places where 63/90 kV designed lines are temporarily operated at 20 kV. Voltage could change, support design not. We're discussing about a numerical limit between both (50 kV) but what about a line with voltage=medium ? Tower or poles ? Fanfouer (talk) 10:01, 29 June 2013 (UTC)

Ok I agree. Let's say "multi-sided" or "multi-legs" structures. Fanfouer (talk) 09:31, 12 June 2013 (UTC)

Neutral distribution

Resolved: Let's say it will do the job Fanfouer (talk) 18:29, 11 September 2013 (UTC)

Let's discuss about the adding of line:neutral=* tag to specify if a neutral conductor is part of a line or not.
Is the name line:neutral is OK ? May we only use neutral=*, it is not currently used according to taginfo : http://taginfo.openstreetmap.org/tags/neutral=yes#overview
This adding imply that when line:neutral=yes and when the line is AC, voltage=*'s value is given between a phase and neutral conductor. Otherwise it's always between two phases.

Visible vs. Not

A visible power line is mapped (rendered) differently from an invisible one, for good reasons. Please don't change the definition of power=line as a visible line. For people who don't care to map down to the strand level, let's ensure there is a simple summary and a simple way to mark what's visible (e.g. the huge power transmission towers and cables traditionally mapped on TopoMaps and OSM) Brycenesbitt (talk) 18:03, 25 July 2013 (UTC)

If we don't change the power=line definition, we still need a consistent model.

Thus, you (not me... I'm taking the easy way) will have to update all adjacent models like :

• highway=* (both roads and train)
• man_made=pipeline

All that tags have independent values from visibility (tunnel=yes, location=underground).

It will cost a hundred proposal, and approximatively 150 years of work to make that consistent to the current particular view of power lines where visible features need special tag and others need another.

Why can't we introduce highway=underground_road, highway=underground_minor_road, highway=little_undersea_road, highway=wide_big_underground_road_of_the_death_with_small_trees_beside ?

The difference between pros and cons here is that I'm not afraid to refine renders, models, processes to have a consistent model easy to understand because it's the same in many fields of knowledge. Not because it's the same as we see reality. Fanfouer (talk) 20:09, 28 July 2013 (UTC)

There does not need to be artificial "consistensy" between different kinds of things. Please stop putting words in other users' mouths; you are the only one proposing any changes to a tag that was documented already seven years ago, so you need to justify that the benefit is greater than the cost of changes to everybody. Alv (talk) 09:55, 29 July 2013 (UTC)

The problem behind power=cable is that there are two main notions in only one tag. First of all it's a power line according to IEC 601-03-03 and it's underground. We do actually have existing and far more general tags (location=underground) to map such things instead of using specific ones. To be versatile, tags need to be atomic.

The same work was done in the Substation refinement proposal : substation may be tagged with location=* instead of introducing specific power=* values.

As said on mailing-list, power networks will be easier to map if we use widely used tags instead of creating ours.

It's all about semantics and intuitiveness.

And for now, proposal is showing how overhead power line is the same as underground power line and they should be tagged the same way : http://wiki.openstreetmap.org/wiki/File:Power_line_overhead_underground_comparison.jpg Fanfouer (talk) 09:32, 17 August 2013 (UTC)

OSM was started as a map data project. We call users mappers. The data is still primarily for making maps. The common convention for making mapping data is, and has been, to use distinct classes (in osm, that's tags) for things that are usually represented differently on maps, or omitted based on that classification. Mappers classify things on the basis of observable characteristics, not on the basis of industry-adopted standards. Does this look equal and similar to this? You'll have a hard time finding a map used by anyone, except the power companies, that represents invisible underground power lines, but you'll find the big overhead lines on most maps. They are physically reasonably distinct from the invisible ones. Alv (talk) 09:00, 22 August 2013 (UTC)

The funny thing is we agree to each other : I'm not destroying the distinguishing between overhead and underground lines by saying location=underground replaces the implicit notion behind power=cable.

You are assuming that maps drawed with OSM data are only geographical maps but it's wider than that. There are logical maps, topological maps or even custom maps. My approach make all that stuff equal right under industrial standards and that's a benefit. Many other kind of maps can be drawn with the same data, let's start to think about tags with that on mind. Fanfouer (talk) 11:26, 25 August 2013 (UTC)

Power vs man_made for towers and poles

Resolved: abandoned. Fanfouer (talk) 20:28, 7 October 2013 (UTC)

This proposal introduce man_made=power_tower and man_made=power_pole where power=pole or power=tower can't be used when there is other Power feature on the same node.
No deprecation for power=tower and power=pole at this time but a strong encouragement to use man_made values instead of power.
This soft transition will allow data consumers and render engines to update their processes and mappers to occasionally replace values where it's needed first.

Values power_tower and power_pole were choosen accordingly to the last days discussion which took place on Tagging mailing-list. We can use man_made=tower + tower=power or man_made=pole + pole=power instead if needed. It would be very appreciated that both tower and pole have the same formalism.

Fanfouer (talk) 15:03, 18 August 2013 (UTC)

Proposal has just been updated with man_made=tower + tower:type=power or man_made=pole + pole:type=power. It's more consistent with other domains like communication when poles or towers support several of these networks.

Proposal has been updated to remove the use of man_made=*. This would be to huge change for this single proposal.

Maybe another one should be setup not only to improve the definition of power lines support but the telecommunication and TV stuff. Fanfouer (talk) 20:28, 7 October 2013 (UTC)

Really? Map every minor line?

Resolved: Yes, map every line if mappers want to. Fanfouer (talk) 18:29, 11 September 2013 (UTC)

In many areas minor transmission lines "line" every street. Perhaps that form of generic facility could be represented by a tag on the highway=*. This block has overhead lines, that block has (presumably underground) utilities. Brycenesbitt (talk) 06:16, 22 August 2013 (UTC)

Really. For overhead minor lines, it's probably as easy as getting all the house numbers complete. "Finishing" the map is a gigantic task anyway, and won't be accomplished unless we have mappers more densely "out there"; when we have, they'll get there eventually - unless the power companies realize it can be more cost effective on the long term to move the lines underground when they're up for renovation. OSM mappers mostly can't spend full days mapping like the state surveyors, but our mappers know their immediate surroundings pretty well; even for the state/city people it took decades, and we're starting from scratch. Alv (talk) 07:27, 22 August 2013 (UTC)

Personnally, I'm not getting closer than the last distribution substation level.

Nevertheless, proposal is giving rules to map such minor lines if mappers want to : power=line + location=overhead + line:neutral=yes + voltage=110 for example.

The proposal's model is extansible in case of new lines type adding. We're not going to think to new power=* values when common tags can already do the job. Fanfouer (talk) 11:27, 25 August 2013 (UTC)

tower:type already used for transmission towers

Resolved: abandoned. Fanfouer (talk) 20:28, 7 October 2013 (UTC)

You propose to use tower:type=power to tag the tower as being a power transmission tower. However, that key is already used for tagging the type of transmission tower, such as anchor, termination or crossing, see power=tower. You will need to find an alternative here. --polderrunner (talk) 19:14, 2 September 2013 (UTC)

That's a very bad news... See tower:type=* : values are designed to distinguish other towers than power ones.

Will we have to move tower:type for power towers to power_tower:type ? Not great anyway... Fanfouer (talk) 21:02, 3 September 2013 (UTC)

Ground conductors (earth wires)

Resolved: Good idea Fanfouer (talk) 18:29, 11 September 2013 (UTC)

I would suggest to add a tag for the number of ground conductors used for lightning protection? I would suggest ground_conductors=*. It would in particular be useful to indicate when there are none, such as in most of Iceland (they have very few thunderstorms there). --polderrunner (talk) 19:20, 2 September 2013 (UTC)

Very good idea :) Proposal has been updated to add ground_conductors=* at the bottom of standard power line tags.

Note that in France, underground power lines also have a ground conductor buried with conductors. Fanfouer (talk) 21:08, 3 September 2013 (UTC)

Rename "cables" and "wires" to more standard terms

Resolved: Abandonned Fanfouer (talk) 20:24, 19 November 2013 (UTC)

The cables=* and wires=* key names were chosen a bit unfortunately in the early days of OSM (see the notes at bottom of those two pages). The more correct terms are conductors and conductor bundle. Thus I would propose the new tag conductors=* to specify the number of phase conductors and bundle=single/twin/triple/quad/.. to specify the type of bundle conductor. These tags should then deprecate cables and wires. But maybe this should go into a separate proposal? --polderrunner (talk) 19:30, 2 September 2013 (UTC)

I agree with you.

Nevertheless, a question that still puzzle me : do we have to specify number of phase conductors (and bundle configuration) on line or on circuit itself (see power routing proposal draft) ?

On a multiple circuit line, we can have a 3-phases circuit and a HVDC one. Thus, frequency=* and conductors will be different for each circuit. If we create a relation to bring all line segments together to form power circuits, we can put each value on the correct circuit. Only circuits=* actually means something on a power=line.

Here we can use ; separated values, but does this has much more sense ?

Don't you want to use numeric values for bundle=* instead of single/twin... ? Fanfouer (talk) 21:08, 3 September 2013 (UTC)

Proposal has been updated with :

* cables=* deprecation in favor of bundles=* for the number of conductor bundles (i.e. arrangement of conductors).

* wires=* deprecation in favor of conductors=* for the number of separate conductor in each bundle.

Each of them accept only numerical values to ease the math processing. Fanfouer (talk) 20:28, 7 October 2013 (UTC)

I retract my suggestion to rename cables=* and wires=*. Your proposed implementation made it much more confusing instead (one reason for the negative voting). The current key names are clearly understood by mappers and lead to few mapping errors. Even if they don't correspond to the "official" IEC terminology I now prefer to keep those keys as they are. No need to redefine tags that are working well. --polderrunner (talk) 08:15, 5 November 2013 (UTC)

The situation changed regarding that : cables=* is now in conflict with power=cable. Actually it can get people confused.

Since power=cable got back in the model for lines with insulated conductors, we must rename the cables=* tag to don't talk about cables for overhead power lines conductors. (without any insulation, only bare-metal conductors).

Nevertheless, in a semantic point of view, I agree that "bundles" isn't the most representative word even if it matches the IEC defs.

Secondly, string values for wires=* (or conductors=*) are just inefficient. We have to use numeric values instead.

I propose to use more complete names : bundles_on_line=*, conductors_in_bundle=*. Or something like this. Fanfouer (talk) 12:40, 7 November 2013 (UTC)

This sounds good to me. It makes it easier for the "normal" mapper to understand what the tags mean. --hendrik-17(talk) 19:32, 7 November 2013 (UTC)

This had been unfortunately removed from this proposal. Maybe some others, more dedicated to terminology, will be needed to refine existing tags. Fanfouer (talk) 20:24, 19 November 2013 (UTC)

Cables in tunnels

Resolved: Moved tunnel=yes to location=tunnel in proposal Fanfouer (talk) 16:14, 5 November 2014 (UTC)

Currently tunnel=yes is documented on power=* for cables in tunnels (used 336 times together with power=* according to Taginfo). I propose to substitute this value with location=tunnel to be consistent with the other location values. It should be used for cables mounted to the walls of constructed tunnels (but NOT for cables buried underground). Dedicated cable tunnels are sometimes used in large cities, see e.g. the London Power Tunnels. --polderrunner (talk) 19:33, 4 July 2014 (UTC)

Thank you to remind me this particular topic. London Power Tunnels are very good references for that.

I agree to replace tunnel=* by location=tunnel and I've edited the document.

How can we represent the link between cables and tunnel if tunnels are also described in OSM ? A relation ?

It can be very complex because many cables sections can be hosted in several sections of tunnels. I may add a section under "Support infrastructure" to describe such tunnels.

The same kind of question can be asked for bridges hosting power cables. Fanfouer (talk) 20:43, 4 July 2014 (UTC)

Both tunnel=* and location=tunnel are attributes defining this object as being located in a tunnel.

They don't define the tunnel itself (the same applies for bridges).

I agree and that wasn't my thought. It was just a question to go further. Fanfouer (talk) 21:48, 6 July 2014 (UTC)

Actually we don't currently have a way of mapping tunnels as such (for bridges there is the proposal man_made=bridge). This is anyway beyond the scope of this proposal!

For cables attached to overground structures use location=overground (this is already documented). --polderrunner (talk) 19:31, 6 July 2014 (UTC)

Point of connection line to substation

Resolved: Added power=anchor to proposal Fanfouer (talk) 21:05, 21 July 2014 (UTC)

No tag for connect line to small substation same small-building for example this Bredy

Really good idea. I would suggest power=anchor or even power=terminal to don't mess up with current poles and towers.

It depend on the meaning of each word and their accordance to the picture. Fanfouer (talk) 20:50, 5 July 2014 (UTC)

I would prefer power=terminal as anchor could be confused with tower:type=anchor. By the way, terminals aren't only found on small buildings. Large 400 kV indoor substations may also have such things (I mapped such terminals just yesterday). --opani (talk) 11:18, 25 November 2014 (UTC)

Then I would suggest power=terminal + terminal:type=anchor instead of power=anchor.

Thus we could consider 3 main famillies of supports : tower, pole and terminal with their own types and properties

And I guess such terminal and anchorage can be different sometimes Fanfouer (talk) 17:29, 26 November 2014 (UTC)

Some suggested smaller changes

Resolved: Solved

. Fanfouer (talk) 21:05, 21 July 2014 (UTC)

I would like to ask the following parts of the proposal to be changed:

• Too restrictive to make "voltage=*" mandatory (it should be a recommended value though).

Ok

• "location" tag for power=line is superfluous (it is per definition overhead) (and "location=overhead" would be redundant to "overground"). For (hypothetical) routing of power lines through tunnels etc. the appropriate location values could be used but such situations are probably extremely rare. Thus remove this tag from the proposal for power=line.

Ok

• Restrict "gas_insulated" to only "yes". Otherwise we will start to see pedantic mappers tagging the 99.9% of features that are not gas insulated with "gas_insulated=no" which would be pure tag pollution.

Ok

• For power cables: "location=undersea" should be "location=underwater" to also cover river and lake crossings. This is the currently documented value.

Ok

tower:type vs. power_tower:type and pole:type vs. power_pole:type

Resolved: Proposal updated with tower:type=power_termination, tower=power_transition and equivalent on poles.

• "tower:type=termination" should stay like that in order to allow simulateous tagging of termination towers and transition towers (a termination tower is not necessarily a transition tower or vice versa). If you use "tower=termination" it is not possible to also tag the transition property. Actually a termination tower is just a variant of "tower:type=anchor" thus it should use the "tower:type" tag which is used for the mechanical role of transmission towers. --polderrunner (talk) 20:02, 6 July 2014 (UTC)

This point need further thinking. You're right, a transition is not necessarily a termination. But there's a little mix up with man_made stuff. tower:type=* is exposing top level role : communication, observation, etc just like "power" but not like a simple "termination" (which is a particular kind of power role) for me.

Without power, termination and transition don't mean nothing. Why should we put them in a common tag ?

How do you feel with power_tower=transition or/and power_tower:type=termination ?

Everything made on towers must be propagated to poles. man_made=pole + pole:type=* don't even exist and the last one should be introduced according to you. Fanfouer (talk) 21:48, 6 July 2014 (UTC)

I support power_tower:type=* because this makes it clear. It is a bit lengthy, but better explicit than ambiguous. --Dieterdreist (talk) 14:38, 7 July 2014 (UTC)

I would prefer to keep tower:type as it is. Otherwise there is going to be a substantial number of wrongly tagged transmission towers. Power towers only have one main role: Supporting power lines. Thus tower:type is used to distinguish the more detailed role the tower plays within a power line (suspension, anchor etc). There is not really a conflict between the two uses of tower:type as the interpretation of the tag depends on whether it is used together with power=tower or man_made=tower. --polderrunner (talk) 21:46, 7 July 2014 (UTC)

How do you feel about tower:type=power_termination - pole:type=power_termination and tower=power_transition - pole=power_transition which would suit both of consistency and detail needs ? Fanfouer (talk) 16:14, 5 November 2014 (UTC)

line=* and cable=*: similarity and difference

Resolved: Split line=* with usage=* and proposal updated.

While line=* and cable=* are intended for tagging of different objects, their role (and their values) is the same. They specify a purpose of the conductor. I think, they should be united into the one same tag. I offer purpose=* or usage=* tag, may be with a namespace: line:purpose=* or power:purpose=*. This modification in the tagging model may simplify parsing in a software. --Surly (talk) 12:47, 20 November 2014 (UTC)

Thank you for this feedback, that's an approach which haven't yet been discussed.

We already have introduced line=* in the substation=* proposal. I understand your point but I prefer to be consistent this approved tag.

Furthermore, even if line=* and cable=* have some common values, a cable can't be a busbar where an overhead line feature can. Group them will create unnecessarily consistency problems.

Once the proposal is accepted, both should be documented correctly. Fanfouer (talk) 14:04, 20 November 2014 (UTC)

In order to keep consistency we should split the different semantics. line=busbar and line=bay specify a construction (a part) of the transmitting system. It's OK with that values of the line=*. But such values as "transmission", "distribution", "minor_distribution", "traction" specify not a construction but a purpose of a line as a whole. And look carefully: a busbar and a bay may be a part of "transmission" line, of "distribution" line and so on. I assure you again, that we should bring a purpose out of line=* and cable=* tags. So we can specify something like line=busbar + usage=distribution. --Surly (talk) 06:16, 21 November 2014 (UTC)

Ok I see your point and line=busbar + usage=distribution is relevant.

usage=* is for now in the Railway group, we can take the key out and make it more global Fanfouer (talk) 08:41, 21 November 2014 (UTC)

Power connections in free air

Resolved: Adding power=connection to the proposal

Intersecting power lines are sometimes electrically connected in free air away from any tower or pole. The conductors are simply connected using short pieces of wire. This solution is often used in Sweden instead of using branch towers. Here is one example. I would suggest to tag such connecting nodes as power=connection. This indicates that there is an electric connection between the two lines but that there is no tower or pole here. --opani (talk) 11:48, 25 November 2014 (UTC)

It's good suggestion. Here is a connection of the same type: 1301165034 1301165034. Here is even not a branch but a connection for parts of one circuit. --Surly (talk) 15:38, 26 November 2014 (UTC)

That's a really good suggestion :) May I extend it to poles where two or more lines are connected ?

All lines sharing the same pole/tower aren't always connected but we can't currently make that distinguish.

In the air without any other feature : power=connection and on a pole/tower : power=pole + connection=yes Fanfouer (talk) 17:24, 26 November 2014 (UTC)

While mapping power lines in the US, I come across similar designs quite often. Until now I've just connected the two lines and left the resulting node tagless. However there also were some already mapped examples, which got tagged power=tap, see f.i. 1815499595 1815499595. According to taginfo it's used 341 times at the moment, although usage seems limited to the US and a quick random sample suggests, that all instances might be from one single user. --TOGA (talk) 23:22, 27 November 2014 (UTC)

I'm waiting to take some pictures of a 400 kV free air connection I know tomorrow and I will update the proposal with power=connection.

power=pole or power=tower where lines are crossing without connection=yes should be assumed without connection. Use tags as such is better to map what actually exists (a connection) than mapping what does not exist (connection=no to indicate lines without connection when crossing).

I've added power=connection to the proposal as suggested.

This tag should be added to possible nodes which can be part of a power line in QA tools.

It was indeed convenient to look at such nodes to detect others shared with roads, fields or whatever. Fanfouer (talk) 09:37, 18 December 2014 (UTC)

Purpose of a tower

Resolved: Use tower:type=* out of the box

I think we need a tag to mark a purpose of a tower (or pole).

We already have the tag for transition towers (tower=power_transition, by the way, why "power_" prefix?). Now we can add the values for marking a termination pylon, a branch pylon, a transposition pylon, a suspension pylon. (May be there are some other kinds of pylons).

The proposal page should have a table with a full list of the purpose values.

--Surly (talk) 09:02, 9 December 2014 (UTC)

It already exists, see Tag:power=tower#Tower_type. The following values are in use: tower:type=suspension/anchor/termination/branch/transposing/crossing --opani (talk) 18:59, 9 December 2014 (UTC)

Never heard of some additional types but they can be added to the proposal if needed. Fanfouer (talk) 14:05, 10 December 2014 (UTC)

Hmmmm... You suggest to put transition towers into tower=* tag, but the other types of a tower (a termination is in the article now) -- into tower:type=*. Why??? --Surly (talk) 12:11, 18 December 2014 (UTC)

It's because a transition tower may be a line termination but a termination isn't always a transition. It was said in case 16.1 Fanfouer (talk) 12:44, 18 December 2014 (UTC)

As for allowing several support types like tower, poles or terminal in power=*, tower:type=* should be converted in support:function=* with values suspensions,termination,anchor,transposing...
tower:type=* doesn't cover poles or terminals but contains values which apply to them.
Furthermore, we can't have values like cooling,communication... referring to the domain of knowledge beside values like suspension,termination... which directly refer to the function of the support Fanfouer (talk) 10:32, 22 December 2014 (UTC)

Special case: South Bridge in Cologne, Germany

Recently the issue of two 110 kV power lines running along the South Bridge in Cologne and how these should be mapped has been brought up on the german forum. With both the current & the proposed tagging scheme it isn't possible to satisfactorily represent reality in OSM.

The lines are attached to crossbeams, which are mounted on the steel archs and between the bridge towers respectively. Until now this situation was mapped with two seperate power lines and power=tower representing the connection points. This of course is totally wrong, as there aren't any discrete power towers standing besides the bridge. Consequently the suggestion was made to map the traverses as with either power=traverse or man_made=traverse and attach the power lines to both endpoints. Additionally one might wish to tag the latter; my proposal would be power=suspension.

For reference, here are some links to examine the assembly:

South Bridge on OSM

Bing Aerial Imagery

South Bridge on Wikimedia Commons with lots of good pictures (make sure to view these at full resolution to see all the details of the construction) --TOGA (talk) 22:21, 9 January 2015 (UTC)

Proposal is now abandoned

As for keeping a small number of keys impacted by the proposal, I've decided to abandon this one a create two subsequent documents to vote them separately. You'll find them here :

• Power supports refinement
• Power paths refinement

No more updates should be done here (Page and Talk). All topics have been copied into the new proposals. Fanfouer (talk) 20:26, 30 January 2015 (UTC)