Proposal talk:Lines attachments

Using clamp for more

Resolved: Power connections aren't line attachments Fanfouer (talk) 16:03, 10 June 2019 (UTC)

This is a good idea. And gave me an idea. Could we perhaps use power=clamp on node for mid air taps that are quite common many places? My knowledge of wiki is not good enough to make a proposition. Gazer75 (talk) 16:56, 27 June 2018 (UTC)

Thanks. Do you think about this? Fanfouer (talk) 17:06, 27 June 2018 (UTC)

Exactly like that and similar Gazer75 (talk) 18:11, 27 June 2018 (UTC)

Well this is not properly a clamp, more a connection or a line, basically. The link on the picture upside is here and mapped as power=connection 4253459503. The clamp is a mechanical device holding conductor, not carrying any power or having any topological role in the electricity travel Fanfouer (talk) 18:51, 27 June 2018 (UTC)

Not really needed on railways?

Resolved: Added more examples in the railway section Fanfouer (talk) 20:55, 12 January 2019 (UTC)

Like the title says, is this tag really needed on railways? Off the top of my head I can't think of any situation where there's not some kind of suspension configuration used. The catenary wire has to be suspended from above or else the attachment would be in the way of the current collector, no? So this would just add the same tag to every catenary mast, which to me seems pretty pointless.
I think, I also have a more general problem with the proposal, but I need to take a closer look again at the older tags, some definitions etc.. I'll add another section about this later today or tomorrow.--TOGA (talk) 03:24, 14 August 2018 (UTC)

Catenary sections should be anchored to masts at their ends. Have a look to this chart.

Feel free to give more comments Fanfouer (talk) 17:43, 14 August 2018 (UTC)

Oh yes, of course. Although this then might get really complicated in a case like this where there's a catenary and contact wire (mixed up terminology above) plus the tensioning of the previous section. I'm not really sure if this is feasable.

This discussion has actually triggered something in the back of my mind with regards to power=catenary_mast. So I've taken a look into the history of this tag and found that originally it was only meant for masts that supported a feeder line. That's also why power was used as the key and not railway. I'm not sure when and why the definition changed. Maybe contacting somebody who specializes in railways might be helpful?

Regardless of the outcome of this discussion, I think it would be good, if you could add some different examples, so one can get a better idea about your proposal.--TOGA (talk) 03:20, 15 August 2018 (UTC)

Rationale & Tagging

I feel like your rationale is a little off. I don't think that the differentiation among the values of tower:type=* is, as you say, based on structure and material, but rather on the function. Depending on the sub-type there can be quite big differences in appearance between two objects of the same type. Structure and material can be mapped with tower:construction=* and material=* or building:material=*.
With power towers tower:type=* works in a similar way, it indicates its function, which in general is the capability to endure one-sided loads. In some ways this actually mimics section 466-06 from the IEC definitions, albeit using different terms. Structure and material are covered by the tags of the same name and the shape, which you want tower:type=* to be freed for, is already described with design=*.

Regarding your proposed tagging I think there are also some inconsistencies. You want to describe how a line is connected to a tower or pole but I don't see how the values of termination and transposing fit into this. With termination the same method of attachment is used as with anchor, so it's not really needed. Transposing towers on the other hand can actually use both suspension or strain insulators. In the US, where I'm mainly mapping powerlines, I often encounter a pair of two-level H-frame towers with suspension insulators that is used to transpose conductors (example). --TOGA (talk) 03:52, 18 August 2018 (UTC)

Thank you for your comments, I hope we'll manage to make the proposal better with this.

Given problem with tower:type=* is terminology. Whatever it deals with material, shape or function the tag name is still :type and doesn't correspond to what it points to.

Secondly, it dedicates to towers some properties which are common to poles, portals, walls or ay power support.

How should we classify line_attachment=termination and line_attachment=transposing as they are also common to poles, portals, other support?

Previously, I thought about support:function=* but this wasn't appropriate since support=* stands for how a feature is supported and not for the support itself.

Finally, this proposal is the solution I bring to strip tower and type to deal with far more general notions. I'm ok to adapt it, but tower:type=* shouldn't be used anymore too Fanfouer (talk) 14:36, 18 August 2018 (UTC)

Hmm, to me type is a rather generic term and it depends on the definition, here in the wiki, what it corresponds to. Yes, self-explanatory tags are nice, but :type is widely used in OSM as a suffix, so I don't necessarily see a problem with it in this case.If I understand your last sentence correctly, it's your goal to entirely get rid of tower:type=* in the context of power towers. So, independent of my opinion whether that's a good or bad idea, the bare minimum for my expectations of such a proposal would be completeness in that regard. Unfortunately with yours this isn't the case as you still have tower:type=branch/crossing remaining.

Concerning your second point, pole:type=* is already used and also part of an approved proposal. Additionally, even you mention it for future use with branch as a value. So here I also can't find a problem with the existing tags.--TOGA (talk) 03:35, 2 September 2018 (UTC)

The fact that :type is widely used in OSM is an issue. It doesn't bring any information while it should. I really like generic and versatile tags, but this is too much. Type is not a knowledge concept, it's only a bag to fill when appropriate words don't come in mind. It may be a necessary step to build OSM, I don't blame anyone to have used it but we can move to more accurate terminology also.

This proposal only strips line clamping values from tower:type=* in the view to completely remove it once a similar solution have been found for branch and crossing. I don't pretend to solve all problems in one shoot, another tag have to be found for this since current scheme mix at least two different concepts in one single key. This proposal will prevent mixing between line attachment and other properties of power supports.

Even if pole:type=* may be already used, we still need it for portals, insulators and terminal, and I'm not in favour to introduce portal:type=*, terminal:type=* or whatever :type. Fanfouer (talk) 21:52, 5 September 2018 (UTC)

Again, as said above, tower:type=* describes from which directions a tower is able to withstand loads and its function. It does not describe which type of insulator is used. While there often is a correlation, it's by no means perfect and for example a suspension tower or pole (called intermediate support by IEC) can also utilise pin insulators. With that said, I don't see the need for terminal:type=* and insulators, in my opinion, are a whole different category. At most, portal:type=* might be needed, although I'm not sure if not all portals are capable of withstanding loads in all three directions.

A question, if you don't mind: If you take a look at your first two examples, there are multiple strings of insulators arranged in parallel. Would it be beneficial to tag the number of those strings, so 3 for the first one and 2 for the second one?--TOGA (talk) 03:37, 15 September 2018 (UTC)

Since it's been a while, here an idea: At the moment I don't see any sensible way to get rid of tower:type=*, especially with regards to the values of branch, transposing and termination. So keep that, maybe change suspension to intermediate, anchor to angle and possibly add flying_angle. At the same we could introduce insulator=* (with or without :type) to tag the information you want to record with this proposal. This would also leave open the possibility to enhance the tagging in the future if you'd want to really go into detail, like for example insulator:material=*.--TOGA (talk) 02:32, 17 October 2018 (UTC)

Sorry for remained away from this proposal for a while. I've removed line_attachment=termination from the proposal and kept tower:type=* necessarily values. Nevertheless, insulator=* maybe out of the scope of this document and will need further thinking. We're currently keeping tower:type=* for very specific values which aren't completely related to line attachment. Is it more correct to you? Fanfouer (talk) 20:45, 12 January 2019 (UTC)

No problem, it's certainly better, but to be honest, I'm not sure if it's really good. There is still the similar issue with the value transposing as shown above. Apart from that, I'm starting to think, that maybe you're trying to do too much with this proposal, covering to many areas all in one tagging scheme, where more specialised tags would be better? That's also why I contacted Nakaner to get another opinion, especially with regards to catenary masts. The newly added example in that section just seemed weird.--TOGA (talk) 04:45, 22 January 2019 (UTC)

I won't go back on replacing tower:type=* wich mix several concepts. Some values were poorly defined and it was right to take them out from the proposal, thank you to give interesting hints to make things better. I'm in favor of reusable tags and concepts isolation in tagging. line_attachment=* now matches completly the idea I want to go for. A vote could possibly start shortly. Fanfouer (talk) 22:55, 23 January 2019 (UTC)

Well, insulator=suspension/strain/pin/shackle/... would also be reusable on all power supports and combined with the already existing power=insulator it would, in my opinion, result in a neatly structured scheme. Of course in the end it's your proposal and your decision. I'm not sure if I wasn't sufficiently clear in my arguments or I'm lacking some English skills to better express them, but maybe the discussion went on long enough and it might be time for a vote anyway...--TOGA (talk) 21:58, 25 January 2019 (UTC)

I would preserve insulator=* for the nature of the insulator (kind of material or nature of what the insulation protects from). Insulation is not only a power subject (think about thermic or noise insulation). That's why the mechanical topic of line attachment shouldn't be taken by the insulators themselves. I'm not sure insulators are the only mean to get a line attachment, especially if the insulator doesn't directly hold the line. Fanfouer (talk) 00:48, 26 January 2019 (UTC)

The material would probably go into material=* or insulator:material=* and at least in combination with power=insulator/tower/pole... it should also be clear for what the protection is. The topic of insulator vs. insulation actually seems quite interesting. Although these terms look similar, there seems to be a distinction when each one is used. For example in combination with buildings you'll overwhelmingly find insulation. And indeed on wikipedia:Insulator (electricity) it is stated that:

Insulators are used in electrical equipment to support and separate electrical conductors without allowing current through themselves. An insulating material used in bulk to wrap electrical cables or other equipment is called insulation. The term insulator is also used more specifically to refer to insulating supports used to attach electric power distribution or transmission lines to utility poles and transmission towers. They support the weight of the suspended wires without allowing the current to flow through the tower to ground.

So generally everything that's wrapped round something, like thermal insulation around a pipe or a building, is called insulation and not insulator. I just saw that you already prepared a proposal with regards to insulation and at first glance it looks ok. I think there's a place for both insulator=* and insulation=*.

With regards to the mechanics of line attachment: Your chosen values might actually be a little bit misleading? Not sure if it's the right word. Anyhow, as stated in your rationale with suspension and strain insulator specific clamps are used. With pin and also shackle insulators it's a little different. There the conductor is led through a groove and then just secured by a wire. For post/line post insulators, as far as I can see, both methods seem to be available. So values like suspension_clamp and anchor_clamp might be more appropriate. For the method used with pin and shackle insulators, I'm not sure which value would be more suitable. Primarily the conductor seems to be kept in place in the groove by its own weight or the tension of the line, depending on if it's used on an intermediate or angle pole, and the wire is just providing additional security. But since the method is the same with both, the value would also have to be applicable to both.--TOGA (talk) 23:00, 26 January 2019 (UTC)

I've updated the proposal after a bit more thinking about this topic. Ok to remove transposition and add line_attachement=shackle.

Currently I think using insulator=* for this is still bad since the goal is to describe the mechanical anchorage and not the insulation.

Hope this is more usable Fanfouer (talk) 22:53, 7 March 2019 (UTC)

The problem with that is that shackle insulators can be used in all kinds of configurations, see the bottom of this page. Also the term shackle clearly refers to the insulator itself and the mechanical attachment, as written above, is a metal tie/binding, see for example this video.--TOGA (talk) 19:29, 29 March 2019 (UTC)

I've got the point and moved line_attachment=shackle to line_attachment=pulley. It covers situations when the cable is hold by the wheel (or shackle insulator) but can move longitudinaly. Fanfouer (talk) 16:02, 10 June 2019 (UTC)

I'm sorry but unfortunately I don't see any improvement with this change. The term pulley, as also written in the definitions at the top of your proposal, implies a movement of the cable which isn't the case with power lines. There, as shown in the video above, the conductor is fixed to the insulator. Even worse the term pulley is used in connection to power lines. It's the device that is used to string new power lines (see here for example or this video). So this could lead to misinterpretations that a power line is still in construction.--TOGA (talk) 02:51, 13 June 2019 (UTC)

Despite the proposal use a lot of example with power lines, the tagging can be used in many more fields of knowledge. Mappers shouldn't use line_attachment=pulley if the support is an actual susension or anchor. The point was shackle was used instead of pulley actually. Attachments with shackle insulators where longitudinal cable movement isn't possible are actual suspension attachements. I see no overlap between 4 proposed values, do you have any 5th value in mind? Fanfouer (talk) 19:15, 13 June 2019 (UTC)

Regarding the newly added example with the power cable in Austria: In this case I would just add support=* with an appropriate value, maybe wall, to the power=cable. Tagging each single mount would, in my opinion, be overkill.--TOGA (talk) 19:29, 29 March 2019 (UTC)

Each single mount can have different properties, and this proposal covers supports. The cable can occasionaly overlap an orthogonal corridor and then not always supported by wall mounted clamps Fanfouer (talk) 16:02, 10 June 2019 (UTC)

You could always split the way and apply a different value to support=* to the new section. By the way, the picture doesn't show very much of the surroundings, so could you maybe describe more precisely where these cables are? I tried to search in the gallery on your homepage but couldn't find this exact image. There are some pictures of similar cables which, as far as I understand, are located inside an indoor substation. This would, in my opinion, be asolutely out of scope for OSM because it is private, very limited access property and can't be seen from the outside.--TOGA (talk) 02:51, 13 June 2019 (UTC)

support=* isn't intended for linear features, and cables aren't split so it's not nice to split them as to document supports instead of using dedicated features for that. Would you like to abandon towers as node and use support=* for overhead power lines? Support key is intended for features located on the same node than their support, this is not the situation of cables on the picture.

Cables are located in a shared infrastructure outside of a substation, point of tagging isn't to know if we're able to map one particular feature but to describe things consistently. I see a support, then I provide tag to describe this support. Fanfouer (talk) 19:15, 13 June 2019 (UTC)

Complex configurations

Resolved: Using pipes in tag value Fanfouer (talk) 20:40, 12 January 2019 (UTC)

I think this kind of numbering in the key is not good as it creates a potentially endless number of different keys. Have you thought of using a syntax similar to that of turn:lanes=* with semicolons and pipes as separators? So adapting this to your example, I'd get line_attachment=suspension;pin;suspension|suspension.--TOGA (talk) 03:59, 2 September 2018 (UTC)

Nice one. I agree that numbering in the key is not optimal. I'll think about your proposition and surely update the proposal Fanfouer (talk) 21:55, 5 September 2018 (UTC)

Resolved: Making tagging consistent with highway lanes Fanfouer (talk) 14:20, 10 June 2019 (UTC)

Nakaner actually suggest to group levels with parenthesis in this Tagging ML thread.

Yeah, looks fine too. Nice work on those graphics by the way.--TOGA (talk) 02:54, 13 June 2019 (UTC)

line_attachement=suspension for catenary masts

Resolved: Railways extension were removed from the proposal Fanfouer (talk) 22:49, 23 January 2019 (UTC)

Thank you, TOGA, for pointing me to this discussion. I am one of the inventors of power=catenary_mast. It was initially invented for catenary masts carrying feeder lines but mappers (including myself) started using the tag for any other catenary mast as well.

I think that the key line_attachement=* is not helpful or suitable for catenary masts in its current form. If you have a deeper look at a catenary mast of a railway line (not a tram line where there is a contact wire only), you will see a contact wire (the lower wire) which is touched by pantograph and a catenary carrying the contact wire. The contact wire is always suspended because otherwise the pantograph would catch the mount of the contact wire at each mast. The catenary is often supported from the bottom (something like line_attachment=pin) but often there is no insulator directly below the catenary because it would be too heavy. Instead, the insulator is located next to the mast (see File:Oberleitung_Radspanner_IMG10010.jpg).

The next issue with your images regarding railway power infrastructure is that they only cover some examples. It lacks examples where the overhead line of multiple tracks is carried by a network of wires, not single masts for one or two tracks. (I don't know a English term, it's called Quertragewerk in German) Examples: Belgium, Germany, How do you want to deal with overhead conductor rails? This is used in narrow and or new tunnels up to about 160 kph. It can be found overground on short sections between tunnels. ([[:File:Murgtalbahn_Stiehltunnel_Stadtbahn.jpg|example)

In curves, contact wires are sometimes not suspended but mounted from the side. Tagging should consider that.

I cannot be in favour of the proposal in its current form. Either you leave out the catenary and limit the proposal on feeder lines when it comes to railway infrastructure or you distinguish between the catenary and contact wire and the feeder line mounted on top of the mast or on the side of the mast turned away from the track. --Nakaner (talk) 23:36, 21 January 2019 (UTC)

Hi, I got your point, thank you. Using this tag for catenaries masts would be too complex. Then I removed the examples about catenaries and railways. We may find a better solution for them later if required

Quertragewerk can be mapped with a dedicated way for carrying wires and nodes at each suspension insulator with power=insulator and line_attachement=suspension. Catenaries may be added if required with a redundancy risk with railways below. Fanfouer (talk) 22:49, 23 January 2019 (UTC)

First example picture for suspension (Elbe Crossing 2)

Resolved: That's indeed anchor attachment Fanfouer (talk) 23:17, 16 June 2019 (UTC)

A small, but potentially important, detail I only noticed just now. While these certainly are suspension insulators, the clamps seem to be anchor clamps. The loop connecting both sides under the insulator is a strong hint and this picture shot directly from below confirms this. It can clearly be seen that the conductors end on each side and aren't just one piece hold with a suspension clamp (for comparison one of the dead-end towers of the crossing with similar clamps, just one-sided). To summarise, this is a suspension tower with suspension insulators and anchor clamps. So the value should theoretically be anchor, since that's how the conductors are attached? With insulator as key this wouldn't be a problem but line_attachment is relative vague in this regard.--TOGA (talk) 03:35, 13 June 2019 (UTC)

Nice hint, thank you. That's consistent with anchor attachment since conductors are cut on the support and kept in mechanical tension with clamps. Vertical insulators are confusing here but I redraw some illustrations as to make it clearer. Fanfouer (talk) 23:17, 16 June 2019 (UTC)

I'm not sure that this seemingly simple solution fully solves the problem. Both in the picture and the corresponding description for anchor you highlight the tensile force from the line affecting the support. But in this example there is no tension on the tower, it just carries the weight.

Additional point in connection with anchor clamps but unrelated to the above. Apparently a cable doesn't necessarily has to end when using an anchor clamp. A single cable can run through two clamps on the same support if a large deviation in direction is needed (see video).--TOGA (talk) 03:02, 24 June 2019 (UTC)

That's right lines not always end on anchors and I've improved definitions to give a better idea of it. I've also added the situation coming from the video on the corresponding schema. Thank you for that point.

It is clear that the mechanical tension is kept in the line on both sides with anchor clamps. I'm not aware of the mechanical calculus on this particular tower and how forces are handled locally. Fanfouer (talk) 21:28, 24 June 2019 (UTC)

Value "pin"

Resolved: Pin should be distinguised from suspension as the last only regards vertical attachment from upside. Pin sounds to be the best word available to deal witht this Fanfouer (talk) 13:20, 14 July 2019 (UTC)

I tried multiple searches but I can't find any reference that describes the situation when a line goes above the support as "pin attachment" outside of the specific case of power lines that are supported by pin insulators. And even in this special field they are not the only type of insulator in this configuration as post/line post insulators can also be deployed in a similar fashion. So I do wonder if this value is really appropriate as a general term. In German the umbrella term "stehende Isolatoren", literally meaning standing insulator, exits but I don't think that this is a good value either. In the example section you, in my opinion correctly, write "...h-frame power pole suspending a 2-circuits power line...", so maybe suspension is the correct term after all?--TOGA (talk) 22:49, 24 June 2019 (UTC)

Given problem is that suspension clearly means the line is suspended (which is wrong on the pin example with the H tower). If pin isn't a good value, I'd be in favour of changing it, but suspension can't be suitable for both situations. Groupings suspension and pin together requires to rename suspension too. It has to be distinguished that suspension attachment is less secured than pin. It also means that if pin attachment fails, conductor has chances to be catched by the crossarm which is less possible with suspension.

If pin is too specific for pin insulators, I may propose raise, vertical_post or even cantilever. Fanfouer (talk) 23:47, 26 June 2019 (UTC)