[Tagging] Feature proposal - RFC - Line attachments

Sun Mar 10 22:02:40 UTC 2019

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

On 2019-03-10 17:54, François Lacombe wrote:
> Thank you for the time took to provide your conclusions here
>
> Le sam. 9 mars 2019 à 19:22, Sergio Manzi <smz at smz.it <mailto:smz at smz.it>> a écrit :
>
>     *A) **Scope of the proposal.*
>
>     It is badly defined. The "Definition" is given as "/Consistently defining how a power, telecom or even washing line is attached to supporting pole or tower/", a very broad definition, but then reading on I see that you state that "/This proposal is mainly dedicated for utilities network//s/". Which one should we take? With the "mainly" adjective are you indicating that you are willing to extend the scope of the proposal to different application fields later on?
>
>     As a matter of fact I'm convinced that a generalization cannot be done in terms of tagging: "attaching" a power line to a fixed infrastructure is done with very different techniques from the "attaching" of a washing line, the suspension line of a cable car, the cables of a suspension bridge, the overhead line of an electric railway (/and I have the strong feeling tha "railways taggers" here have their own ideas on how to tag their contact lines/), etc., and therefore will require different tagging schemes.
>
> Since tagging is built by contributors here, yes all is extendable by further proposals.
> It's hard to get a whole topic described in one shot so anyone will be able to propose more precise tagging for insulators for instance.
>
> Generalisation is made upon shared concepts. Whatever the line is, an anchorage is still an anchorage.
> Additional keys can precise how the anchorage is made, and so on
>
>     *B) **Inconsistency between the proposal name and the tag name.*
>
> Solved, proposed renamed accordingly.
>  
>
>     *C) **Are we really talking about "Clamps"?*
>
>     The images you are attaching to the definition of "suspension_clamp" and "anchor_clamp" are misleading in the sense that one could easily take what in reality is a "Suspension insulator set" as a "Suspension clamp" and a "Tension insulator set" as an "anchor clamp".
>
> Right. Clamp term is removed from the proposal and values.
> As the rationale stands to share concepts between power, telecom or any supported line, it's out of the scope to define insulators sets, chains and so on.
> The point is to provide tags to make the distinguish between suspension, anchorage and shackles.
>
>     The confusion is even more augmented by the fact that in your proposal you refer to "shackle insulators" too (IEC 471-03-09), and they are in a totally different area of the IEC standards, "Insulators", same as "pin insulators" (IEC 471-03-06).
>
> Shackle insulators are the basis to define shackles and how they differ from suspension and anchors/tensions.
>
>     So, are we talking about clamps (fittings) or about insulators (/or insulator sets/) here? Because it really seemsyou are mixing under the same tag two very different kind of objects...
>
> We are dealing with attachments, which only involve insulators with bare power conductors.
>
>     And BTW, how could you then tag "the real clamp" with its bolts and nuts when it comes to it?
>
> Keys have to be proposed for that, it's not the point of the current proposal.
>
>     *D) Inaccurate wording. *Some examples:
>
>       * You state that "anchor_clamp" is "/built stronger than suspension tower//s/". Really? A clamp stronger than a tower? :-/
>
> You're confused in your own reading.
> First sentence begins with "A support" (referring to a tower/pole) and second goes on with "it is", implying that an anchor tower is built stronger than a suspension one.
> Nevertheless I rephrased the whole definition as to make it more clear.
>
>       * "/A shackle insulator may be used to hold conductors safely from their support/" Isn't that the meaning of the life of *every* insulator?
>
> ... without any clamp, that's what I forgot to mention.
>
>     *E) Logical mishaps*
>
>     In "Complex configuration", under the image of a pole with two levels of conductors (/3 on the higher plane, 1 below "on the right"//watching the image/), you state that "/Values would go _from right to lef_//_t_ / top to down of the pole while values in each section would be given _from left to right_ in the direction of the way passing by the support node/". I _really_ don't understand what you are trying to say. Sorry for asking, but right and left wouldn't just swap if I watch the pole from the opposite side? (/and yes, as others already pointed out, semicolons have a different meaning in OSM tagging/)
>
> Right, that was not clear at all and has been rewritten.
>
> Regards,
> François
>
> _______________________________________________
> 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/20190310/be3ed801/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/20190310/be3ed801/attachment-0001.bin>