Proposal talk:Power supports refinement

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)

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)

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)

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)

Point of connection line to substation

Resolved: Added power=terminal to proposal Fanfouer (talk) 21:05, 21 July 2014 (UTC), then moved it to power=insulator Fanfouer (talk) 16:11, 10 April 2015 (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)

Proposal has been edited to move power=terminal to power=insulator according to case 10. Fanfouer (talk) 16:11, 10 April 2015 (UTC)

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)

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)

Power Portal?

I've never heard the term "power portal" as used in this proposal, and nothing like what you've described came up with a quick Google search. Can you give a rationale/reference for using this term? Neuhausr (talk) 20:46, 30 January 2015 (UTC)

Thank you for making me look at the Rationale/Definition links. The IEC link for power portal support was broken.

According to IEC ([466-07-02]), a portal is composed of two vertical supports linked by a horizontal crossarm near its top. This correspond to the picture I've added in the example section.

Adding power=portal is useful to describe features more or less far from the definition of the simple lattice tower. Fanfouer (talk) 21:38, 30 January 2015 (UTC)

Large portals can be presented as a linear object. Maybe we should allow to map such supports as a way, not only as a node? --Surly (talk) 15:31, 31 January 2015 (UTC)

I find it interesting but hard to handle in a QA way.

This proposal aims to deal with power lines supports, mainly nodes of ways. How would you test if an intersecting node of two ways (power line and power portal as a way) is a support or not ? Fanfouer (talk) 14:06, 1 February 2015 (UTC)

The problem I see at the moment is, that the IEC-definition, you've linked to, mentions "H" frame towers, whereas your proposal explicitly exludes these. To me that just makes no sense.

The proposal doesn't exclude h-frame towers. If the tower really (with cables carried outside of its legs) is h-frame designed, it should be tagged with power=tower + design=h-frame. Fanfouer (talk) 15:27, 3 February 2015 (UTC)

Sorry, I shoud probably have been more clear. What I meant to say was, that "H"-frames are excluded from the power=portal-section of the proposal. I hope that clarifies it. --TOGA (talk) 23:15, 4 February 2015 (UTC)

Sure they actually are excluded from power=portal since they aren't. H-frame towers are towers, thus they should be tagged with power=tower only. Fanfouer (talk) 09:20, 12 February 2015 (UTC)

Ok, I think you still don't understand my point, so let's start from the beginning:

You base your whole proposal on definitions from IEC and Wikipedia, in the case of power portals only on one from IEC. Listed under "Overhead lines"->"Poles and brackets" we find number 466-07-02 "portal support" and it states the following:

portal support

"H" pole

"H" frame (US)

a H shaped support comprising two spaced vertical main legs with a horizontal crossarm near the top

As you can see, this definition puts "H"-frames, which are currently tagged with power=tower + design=h-frame, into the same category as portals. So if we go by this, shouldn't these theoretically be tagged as power=portal? To be consistent, I think we would have to, but that then again introduces the whole problem of having to retag something like 100k objects. Cheers, --TOGA (talk) 23:10, 24 February 2015 (UTC)

At the same time I'm very sceptical of changing the proposal according to the definition as design=h-frame is the - by a huge margin - most widespread value for design=* , see taginfo. On the other hand I definitely do feel the need to map larger portal-like assemblies, like f.i. this one, which currently is not possible, at least not satisfactorily. Maybe one could map these as ways, as Surly suggests, and tag the node, where the line connects to the assembly, with power=terminal? --TOGA (talk) 23:28, 2 February 2015 (UTC)

H-frame are towers and portals are... portals. The proposal aims to map both and doesn't replace design=h-frame.

Your idea to use power=terminal at the intersection of a power=line and power=portal is clever, thank you.

Nevertheless, we can't use power=terminal at intersections with power lines. In substation, portals aren't always terminals but simple supports. I think we need a fifth feature for anchors on buildings instead of terminals. Fanfouer (talk) 16:03, 3 February 2015 (UTC)

In this case I would prefer not to introduce an additional main feature, but rather use something like power=xyz & xyz=terminal. --TOGA (talk) 23:15, 4 February 2015 (UTC)

Power portals are currently mapped in two ways: The original way was/is as power=portal. This tag is primarily used for portals within substations. The second way is as power=tower + design=portal. This tag is used both for substation portals and for transmission towers fulfilling the definition of a portal.

Concerning the definition of a portal: According to design=* a portal is a support structure having two or more supporting legs and all of the cables being supported between the legs. If some of the cables are supported on the crossbeam extending beyond the legs it is to be considered as an design=h-frame tower (this term is common in e.g. the US) and this tower type is very common in North America and in Scandinavia. Your first example of a portal is actually an h-frame tower by this definition! --opani (talk) 18:53, 1 February 2015 (UTC)

I Agree, thank you. Proposal will be updated.

Nevertheless, French TSO calls "Trianon Portal" the feature of the first example. Fanfouer (talk) 19:16, 1 February 2015 (UTC)

It may actually be desirable to distinguish between portals inside substations and real transmission towers of a power line that happen to be of the portal design. Therefore I would suggest to use power=portal for any kind of portal support structure inside a substation that cannot be considered a transmission tower while use the tower+design tagging scheme for transmission towers of the portal design (they are not that common). --opani (talk) 18:53, 1 February 2015 (UTC)

I find desirable to distinguish real towers from portals wherever they are located. According to definitions, using power=tower + design=portal instead of power=portal (if introduced) is confusing. You first say "it's a tower" and then "no it's not". power=tower shouldn't be used any more on any feature with another structure than tower.

Inside / outside substation can be determined by looking at topology with spacial functions. Fanfouer (talk) 19:16, 1 February 2015 (UTC)

Nongeneric values in design=*

Resolved: Added design:ref=* to proposal. Fanfouer (talk) 09:05, 12 February 2015 (UTC)

At the moment the proposal states that design=* "may include the operator's internal reference". I think it would be good to keep the values as generic as possible, so a data user can utilise these without knowing every internal reference or model number from operators around the world. I would suggest two potential solutions:

1. design:ref=*
2. As is used for wind turbines: manufacturer=* & manufacturer:type=*

--TOGA (talk) 18:05, 5 February 2015 (UTC)

Good idea. I have actually considered adding that tag to power=tower feature page (there is already design:name=* which should only be used for explicit names given by the designer). In the UK the various tower designs are referred to designations such as L6, L12 etc which would be natural to add to the ref tag. However, I'm not aware of other countries using similarly designations. The design=* tag must absolutely be a generic tag having standard values valid worldwide. Otherwise the tag becomes pretty much useless as there would be a zillion possible values. My Maperitive tower rule set relies heavily on standard values of this tag. --opani (talk) 20:41, 5 February 2015 (UTC)

I agree, proposal has been updated with design:ref=* Fanfouer (talk) 09:05, 12 February 2015 (UTC)

Special case: South Bridge in Cologne, Germany

Resolved: Power line supports can now be tagged with power=insulator. Fanfouer (talk) 16:13, 10 April 2015 (UTC)

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)

I don't see any objection to use power=suspension.

Furthermore it would be good to use it with power=portal on connection points between the portal and the line.

We can merge it with power=terminal since a terminal is a kind of suspension : power=suspension + support_function=line_termination.

This value solve many border-line issues and can prevent us to clutter the power=* key with many much other support types. How do you feel with that ?

Just waiting for your opinion before updating the proposal Fanfouer (talk) 18:18, 14 March 2015 (UTC)

Usage of power=portal has also been suggested at the forum and I agree that this could be a good solution. We would just need a special value for design=* indicating that this element only represents the horizontal support and the vertical structures are separate objects; design=fixed_traverse or simply design=traverse are possibilities.

Simpler version : the represent the horizontal support and the poles (they may be tagged with man_made=* stuff or whatever). No need of excess tagging there don't you ? Fanfouer (talk) 20:42, 17 March 2015 (UTC)

Sorry, this solution stands for a general power=portal mapped as a . Regarding the bridge, support outside the between the structure and the line is out of the scope of this proposal. Tags used won't interfere. Fanfouer (talk) 20:45, 17 March 2015 (UTC)

Sorry for the late answer, I agree that for normal portals simple are sufficient to represent the legs. I wouldn't even tag those, just mark them with a . But as you said this is a special case and I think it would be good to add a tag so one would know that untagged nodes which are part of the power=portal do not represent a simple leg but a seperate structure.--TOGA (talk) 21:59, 9 April 2015 (UTC)

I also agree that merging power=terminal into a more general purpose value would be really great. However I'm having secound thoughts on the word "suspension" because it hints at the insulators hanging down from the support. This though isn't always true as there are obviously strain or even standing insulators. So maybe something like "attachment" or "fixture"? --TOGA (talk) 18:28, 17 March 2015 (UTC)

I agree to the restrictive side of power=suspension. What about power=insulator instead ? And we can indicate their position or arrangement with design=* (for exemple : design=horizontal, design=vertical, design=V or whatever). Fanfouer (talk) 20:42, 17 March 2015 (UTC)

Yes, insulator sounds good. But to add detail I probably would use insulator:*=*. That way you can also specify the type of insulators used on towers if needed.--TOGA (talk) 21:59, 9 April 2015 (UTC)

It's ok, proposal has been updated and this kind of bridge (and many other) will be "mappable" with the new tags. Fanfouer (talk) 16:11, 10 April 2015 (UTC)

Hanging insulators

Resolved: Use power=insulator as or on the part of the power line corresponding to such hanging insulator. power=terminal restored in the proposal. Fanfouer (talk) 16:58, 13 May 2015 (UTC)

Recently I saw rather special configuration of a power network with a hanging insulator.

Here is the place: 3428489376 3428489376

• 1, 2 - power towers bearing trunk power lines.
• 3, 4 - branches to a substation.
• 5 - insulator. Branch lines are fixed to each other by means of this insualtor; with no electrical conection.
• 6, 7 - connections
• 8, 9 - substation's circuit breakers

I suggest to map such insulators with power=insulator on its a node or its line:

• 1, 2 - a node with power=tower.
• 5 - power=insulator (a node on the upper map, a line on the lower map)
• 6, 7 - nodes with power=connection
• 8, 9 - substation equipment mapped as needed

The lines between 1 and 5, and between 2 and 5 must be different line objects with power=line.

--Surly (talk) 06:24, 2 April 2015 (UTC)

Thank you Surly for such a nice case. I've seen it in France too a couple of months ago.

I agree with power=insulator. This tag has just been introduced in the Proposed_features/Power_supports_refinement#power.3Dinsulator power support refinement proposal as a support.

It may be currently hard to make the distinguish between a wall mounted insulator (power support) and a hanging one don't you ? I'll add to the proposal that a power=insulator need to share 2 ways to be a support (one for the line and another for the wall or portal which carry the insulator). Fanfouer (talk) 21:01, 16 April 2015 (UTC)

It may be currently hard to make the distinguish between a wall mounted insulator (power support) and a hanging one don't you ? -- That's why I recommend to keep power=terminal for a wall-mounted supporting device (it consists of an insulator and some metal mounting parts, not only of an insulator).

Every use of power=insulator includes the metal mounting part (you find it even on the hanging ones). There is no extra stuff on a terminal compared on a simple anchor on a bridge arm or whatever. Fanfouer (talk) 17:28, 17 April 2015 (UTC)

Ok to restore power=terminal in the proposal. Fanfouer (talk) 16:58, 13 May 2015 (UTC)

And please allow tagging ways with power=insulator.

This is done. Fanfouer (talk) 17:28, 17 April 2015 (UTC)

Make clear that rendering section is a suggestion

I would suggest that in future language in "Rendering" would make clear that it is suggestion - "power=portal may appear with (...)" would be much better than "power=portal should appear with (...)" Mateusz Konieczny (talk) 09:16, 14 May 2015 (UTC)

FOr me it's the same, we are both agree. Nothing is mandatory regarding rendering. It's only some advice or views, render managers will do choices on their own. Fanfouer (talk) 12:10, 14 May 2015 (UTC)

colour with multiple values

What exactly are the semantics of the multiple colour values, i.e. which colour would be where? --Tordanik 11:17, 14 May 2015 (UTC)

It's only a list of visible colours on the power supports. e.g colour=red;white for a red and white tower. No additional information required. Fanfouer (talk) 12:09, 14 May 2015 (UTC)

But that doesn't tell us where which colour is, e.g. does it have red and white stripes? Is the upper half white and the lower one red? Without that information, it's pretty pointless, and doesn't justify changing the values allowed for an existing key. --Tordanik 16:27, 19 May 2015 (UTC)

No it doesn't because it's a bit hard to describe such precise information. There are many different possibilities and it may require several other keys. Do you have any proposition as an improvement ?

I admit I've moved values to ; separated lists. It's only to be consistent with other keys and maybe one day compatible with ;-able software. Fanfouer (talk) 18:54, 19 May 2015 (UTC)

support:function

I think the key is somewhat problematic because it looks like a refinement of support=*, when it is actually unrelated. I would be in favour of changing it so something else, e.g. power:function. --Tordanik 11:19, 14 May 2015 (UTC)

Voting has began and such changes can't be done easily I'm sorry. This proposal had been under RFC status for months. As usual : why such question didn't pop up before ? Fanfouer (talk) 12:07, 14 May 2015 (UTC)

It's not only a power matter, support_function=* gives information on the role of any support. It allows us to introduce only one key instead of pole:type=*, portal:type=*... It sounds important to me.

It's not so inconsistent with support=* : any support actually support something and this key is here to say how it is. Fanfouer (talk) 12:31, 14 May 2015 (UTC)

Unfortunately, it is inconsistent. The support key is not used on supports, but on the objects supported by them. That alone makes the two uses of the "support" term incompatible.

Ok I didn't get it that way. It's now clearer, thank you. function=* is too generic and may cause other issues. power:function=* isn't a good solution because it's not only a power matter. For now I don't see other solution and need to think about it. Any idea ? Fanfouer (talk) 19:13, 19 May 2015 (UTC)

As for why that question popped up so late, I simply missed your proposal until then. I read the tagging list, but simply did not notice your proposal before. --Tordanik 16:38, 19 May 2015 (UTC)

Honestly it disapoint me a bit to put all that stuff together and see there is such mistakes. It will need improvements at the end of the vote, let's hope we'll find out a good solution. Fanfouer (talk) 19:13, 19 May 2015 (UTC)

Example images

The picture of a tower in France has two supports and a horizontal crossarm at the top which makes it a portal not a tower.

According to design=* (https://wiki.openstreetmap.org/wiki/Tag:power%3Dtower#Tower_design), portals are considered when cables are inside the legs. The French example picture shows that there are actually 2 out of 6 cables outside the legs. Thus, this support is considered with power=tower + design=h-frame.

It's the current definition given for design key and this proposal doesn't change it. Fanfouer (talk) 22:45, 14 May 2015 (UTC)