[Tagging] Feature proposal - RFC - Line attachments

Wed Mar 13 00:20:24 UTC 2019

Hello François,

So, your updated picture made it clear that it is the "insulator set" what should be mapped with your newly proposed tag. I suppose  that for power lines the same would be true in case the "line attachment" would be through a "pin insulator" or a "shackle insulator" or every other form of insulator.

So, when one is supposed to use the "power=insulator" tag instead?

The wiki for that tag (/which *you* wrote/) is describing insulators as "/Power insulator linking a power line to a support/" and also "/It's a power insulator linking an overhead line to another (grounded) infrastructure/".

In the examples there is also a picture of a concrete portal with the caption stating: "/Support : Insulators are used to *anchor *the power line on a concrete portal/".

*So we should tag the same node as both a "power=insulator" and "line_attachment=suspension", or should we map a distinct node for the "line_attachment"?*

I would barely understand if you only had *two values* for line_attachment *as properties of the "insulator" key*: suspension and anchor, distinguishing if the vector of forces on an insulator add-up to an essentially vertical vector because the "traction" forces of two catenaries compensate each other and you just have a vertical component of force at the binding post (/suspension/), or you don't have the compensation of the two catenaries (the line is attached to a fixed post or the two catenaries are not compensated) and you also have an horizontal component of force that the binding post must sustain (/anchor/). Not much useful to know, IMHO,  but hey, who am I to judge that?

But that's not the case, unhappily! In your proposal you also describe "/shackle insulators/" and "/pin insulators/" as "line attachments". For me they should have been documented in the "insulator" key as types of insulators (/yes, Warin, I know you dislike "type" and it goes under your skin.../).

*A**s I wrote you in our personal mail exchange I have the feeling that you are trying to map "concepts", not "things", through generalization: the Platonic idea of a line attachment in this case.*

You're doing the same in your current proposal about "substations" (/https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_functions/), where you want to generalize the concept of "substation" and apply it to both the domain of power distribution (power) and fluid distributions (pipeline).

That's profoundly wrong in my opinion and I strongly feel that this should stop: we are not here "to put order in the universe" and categorize a and "name things" (/I'm an atheist, so I'm not much informed about this things, but I seems to remember that the Bible talks about that.../), we are here to map useful information about things.

And the above, of course, is in addition to my basic objection about mapping things that I think are more fit to AutoCAD or CATIA than OSM...

Cheers,

Sergio

On 2019-03-11 23:35, François Lacombe wrote:
> Hi Sergio,
>
> The proposal aims to map the way lines are bound to their supports.
> In my mind, attachement = {Insulator set ; clamps ; accessories to secure the insulators on crossarms} for a bare power conductor.
> Further keys can give details about each item in this set (but out of the current proposal).
> For insulated cables you don't have insulators but the attachment methods are the same.
>
> Here are illustrations :
> https://wiki.openstreetmap.org/wiki/File:Elbekreuzung_2_traversen_crop_suspension.jpg
> https://wiki.openstreetmap.org/wiki/File:Power_cable_suspension_attachment.png
>
> Keep in mind that currently, it is possible to give the same information with tower:type=suspension.
> As explained in the rationale, :type suffix is meaningless and gather too much possibilities to be usable.
>
> Hope it's clearer
>
> François
>
> Le dim. 10 mars 2019 à 23:04, Sergio Manzi <smz at smz.it <mailto:smz at smz.it>> a écrit :
>
>     François,
>
>     Thank-you for addressing the mistakes I outlined (/some still needs some polishing I gues/s), but anyway (/and putting aside my reluctance to map such things/) I'm afraid there is still something profoundly wrong with this proposal, at its very essence.
>
>     I still don't understand what are *the objects* that one is expected to map with this tag.
>
>     Taking as an example the first tower you depict for "line_attachment=suspension" (https://upload.wikimedia.org/wikipedia/commons/5/50/Elbekreuzung_2_traversen_crop.jpg) what are they? The tower (/BTW, shouldn't it be pylon in Brit. Eng. ?/) The "/branch/" (/sorry, I'm missing the correct word.../) of the tower/pylon to which the insulator sets are suspended? The rings/hooks/bolts/nuts suspending the insulator sets under the "branch"? The insulator sets themselves? The clamps suspending the conductors under the insulator sets?
>
>     Would it be too much asking you to edit the picture by adding a red arrow pointing to the object of this tag?
>
>     TIA,
>
>     Sergio
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190313/c644a244/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3675 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190313/c644a244/attachment-0001.bin>