[Tagging] Feature proposal - RFC - Line attachments

François Lacombe fl.infosreseaux at gmail.com
Mon Jun 10 16:31:30 UTC 2019

Hi all

Following the pretty long discussion occurred in March, the proposal has
been updated again with two main improvements :
* Moved line_attachment=shackle to pulley since shackle was not used in a
proper sense.
* Improved examples, especially for complex configurations for which
parenthesis are used consistently with what is done for highway lanes

Despite the proposal is focused on utility networks, tagging should be
suitable for any line
Terms and concepts may be extended later to better match any further need
in a particular domain.

As climbing bolts were raised as a concern in previous discussions. The
support feature "bolt" is out of the scope of the proposal
You can use them independently as anchors or hold ropes with appropriate
pulleys (and the attachment is in the scope)
Permanent bolts would be supports similar to power=pole or power=tower for
power lines and they still need a dedicated tag to be mapped in OSM I guess.

Expect the vote to starts shortly if no further objection raise out of this
thread or Talk page.

All the best


Le mer. 13 mars 2019 à 18:55, François Lacombe <fl.infosreseaux at gmail.com>
a écrit :

> 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
> documents
> 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 clamps.
> 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.
> https://wiki.openstreetmap.org/wiki/File:Portal_portal_as_way.png
>> *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 that.
> To me this is also shackle attachment :
> http://aac-publications.s3.amazonaws.com/anam-13201213050-1424994510.png
>> *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
> François
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190610/d258559b/attachment-0001.html>

More information about the Tagging mailing list