[Tagging] Feature proposal - RFC - Line attachments

François Lacombe fl.infosreseaux at gmail.com
Wed Mar 13 17:55:35 UTC 2019

Hi Sergio,

Thank you for feedbacks, my answers below.

One general reminder:
I'm not the one who start to map nor line attachments, nor substations
shared between pipelines and power lines.
tower:type=anchor, tower:type=suspension and pipeline=substation were
already widely used and reviewed.
Tagging should be improved for the sake of benefits listed in proposed

Le mer. 13 mars 2019 à 01:21, Sergio Manzi <smz at smz.it> a écrit :

> 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.
In case of power line, the insulator set (chains + linking accessories) AND
Yes it may be the same for other values which I can provide similar pictures

> 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*".
When the support is mapped as a separate object. For instance a portal
mapped as a way. The shared node between the portal and the line gets
power=insulator + proposed line_attachment.

> *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"?*
When power=insulator is applicable, the same node can get a line_attachment
tag also. There is not always an insulator involved with line attachment.

In case of a tower mapped as a node (most of them), we can't mix
power=tower and power=insulator on the same object.

> 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...*).
As Warin, I also dislike the type tags.
Lines aren't always attached with insulators, unfortunately.
Previous discussions shows that pin attachment isn't equivalent to
suspension one and I already adapted the document for that as I remember.
Shackle insulators and pin insulators are particular situations for shackle
and pin attachments. I should provide more example without insulators for
To me this is also shackle attachment :

> *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
> <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.
Could you elaborate on why is this wrong please?
I agree on concepts vs things (while I consider things as a particular kind
of concepts) but the point isn't to put order in the universe, just share
concepts and reuse established works.
OSM is also known through this.

All the best

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190313/4f350695/attachment-0001.html>

More information about the Tagging mailing list