Proposal talk:Lines arrangements

Key:design

Resolved: added in rationale

I think it is important for this proposition to explain why we need a new key that have a lot of similarities with design. Cheers. --Ydel (talk) 13:22, 20 April 2023 (UTC)

Good point, I'm currently writing the proposal and it will be done shortly. design=* is kind of more precise than arrangement, a single arrangement can be achieved with several different design=*. Some designs could also lead to different arrangements: H-frame can support two horizontal circuits or two triangular circuits as well.

Designs varies from a country to another, very specific to environment and weather actually. That's why it could be useful to have both on OSM. Fanfouer (talk) 20:10, 20 April 2023 (UTC)

multiple values

Resolved: Complex configuration are currently discouraged and a further proposal will be reviewed for matrix values

In the examples, I find some using multiple values, so, I guess; they should be allowed. The examples use | instead of the common ; as separator. Is there a reason for that? Could we, please, have one or two general sentences about multiple values and the separator to use. Thanks. --Skyper (talk) 14:24, 1 May 2023 (UTC)

That's a good point as well, thank you. Complex notations are the same as line_attachment=* and line_management=*: supports are defined as tables with columns and rows. It is inspired by lanes=* usage and was discussed in lines attachment proposal.

I intended, but not yet finished, to build a more global framework out of this kind of values, in Matrix_values.

This will be added to the proposal shortly, and (triangle|horizontal) is actually wrong. Since it regards different levels, it should be (triangle)|(horizontal). Fanfouer (talk) 17:00, 1 May 2023 (UTC)

I see. I missed the proposals in 2019 and now it is probably too late but @Nakaner suggested to add a suffix *:cables=* similar to *:lanes=* back then. This would make it easier for QA and editor software. I still have no solution to create a proper preset for Lanes tagging in JOSM, atm, and introducing even brackets and numbers in addition won't make it easier. Matrix_values looks interesting. (In fact I could use it for complex timetables in public transportation routes.) But I guess we need a broader discussion about it and editor software support plus I would always use a suffix. --Skyper (talk) 12:05, 2 May 2023 (UTC)

First of all, this tagging is not perfect and subject to further change, even after 2019 discussion and proposal approval. So it's not too late and we could improve it again.

By the way, I actually still don't get what could bring a *:cables=* suffix in the case of line_arrangement=*. What should it distinguish? It won't simplify the table actually, as we only document one single property.

UX in editors for lanes, attachments or arrangements can't be solved with current tool set. We need a table editor to change the content of each cell inside. Given problem is we currently don't have any key to define the table structure prior to fill it. Should we define a supplementary key like support_levels=2;3 defining a 2x3 matrix allowing to use line_attachment=(suspension|pin|suspension)|(anchor) (second level anchor is common to the 3 slot and is equivalent to anchor|anchor|anchor on this row)? Fanfouer (talk) 12:25, 2 May 2023 (UTC)

Good to know that it is not carved in stone and that we are still evolving the tagging. Instead of *:cables=* how about *:lines=*? We still could use mixed or multiple as single value for line_arrangement=*, line_attachment=* and line_management=* for consuming software without matrix value support. I think defining the matrix dimensions with keys is not needed as this could be done when setting the values by simply adding more columns and rows in UX. In fact, there is no key for that in Lanes tagging either but this makes QA more difficult. At least, I now have more inspirations for JOSM ticket and need to update it to ask for a new general matrix like value input. --Skyper (talk) 12:59, 2 May 2023 (UTC)

Well, if I understand it correctly, the suffix is only there to separate simple values from matrix ones, right? Currently with line_attachment=*, anchor value is equivalent to (anchor|anchor|anchor)|(anchor|anchor|anchor) when all levels has got the same attachment. And you'd be in favour of separating them both?

We could think about *:matrix=* for any key to spread values in a 2 dimension table. That would be generic enough.

Really happy to bring inspiration to a 10 years old ticket, that's how OSM improves Fanfouer (talk) 20:00, 2 May 2023 (UTC)

Yes, I propose a suffix to separate simple from matrix values. If all values are identical a single simple value is enough but matrix values are still possible like line_attachment=anchor plus line_attachment:matrix=2(anchor|anchor|anchor). Same is true for Lanes tagging, e.g. turn=left plus turn:lanes=left|left|left or change=no plus change:lanes=no|no|no where the simple values are enough. With multiple mixed values we could then use line_arrangement=triangular;horizontal or line_arrangement=multiple and both times line_arrangement:matrix=(triangular)|(horizontal).

I am fine with *:matrix=* though the general approach probably needs more discussions, more time and a separate proposal. --Skyper (talk) 12:40, 3 May 2023 (UTC)

I'm good with *:matrix=* too. Then it could be ok to propose line_arrangement=* with simple values only for now and then refine line_attachment=* and line_management=* in a further proposal with *:matrix=*. I'll then edit the proposal shortly and remove the complex example.

The second proposal will be a good opportunity to consolidate Matrix_values. Fanfouer (talk) 20:46, 3 May 2023 (UTC)

t pylon

Resolved: Example has been added

Perhaps add the T-pylon to the examples. https://www.nationalgrid.com/national-grid-energise-worlds-first-t-pylons RobJN (talk) 13:32, 7 May 2023 (UTC)

Hi and thank you for this suggestion. Would you agree T-shape can be design=* and the arrangement is line_arrangement=delta? Fanfouer (talk) 16:47, 7 May 2023 (UTC)

I wasn't sure, which is why I thought I'd make a good additional example. RobJN (talk) 18:37, 7 May 2023 (UTC

It would be good to add indeed. Unfortunately, I can't find any suitable picture in Wikimedia Commons. Would you mind adding one if you're able to take some in your surroundings please? Fanfouer (talk) 17:48, 8 May 2023 (UTC)

Underground cable mapping

Resolved: Clarification has been made

Disclaimer: I don't have any knowledge about this topic. But I don't find the two mapping option very relevant for underground cables : if you tag the point where the line arrangement changes, does the tag applies for before or after this point ? What about if someone reverses the way ? How data consummers can differentiate a node tagged in the middle of the cable with no line arrangement changes and a node at a line arrangement changes ? Plus, in case of someone reshapes the underground cable, I'm afraid he won't take care of the line arrangement tag on few points, thus leading to poor data quality if he mooves / delete /add points. Thus, imho, for underground cables, it should be better to tag the line arrangement on the cable itself, not on nodes supporting the way. In contrary for aerial lines, I find it totaly relevant to map it on nodes. Thanks for the proposal. Babouche Verte (talk) 04:04, 23 May 2023 (UTC)

Hi, it's true the proposal isn't so clear about this point and should be a bit reworked. I'll spend a few time on it shortly.

By the way, the recommendation about underground and arrangement changes is to tag nodes that comprise a consistent section of a given arrangement. Reversing the way hasn't any effect on that.

A drawing should make that clear, wait for it

Finally, line_arrangement=* should remain valid on nodes only as to not clutter geometries, even underground. Tagging cables themselves won't solve the reshaping problem as you'll have to take care of where a given arrangement starts and end or not (and open data should help and complete what we see on ground during construction works). Fanfouer (talk) 21:27, 23 May 2023 (UTC)

I think this picture explains it a little more clearly, right?

Fanfouer (talk) 22:23, 30 May 2023 (UTC)

The picture is indeed clear, we could add "The line_arrangement of the underground cable is the value of the first previous and next node with a line_arrangement=* tag, if the same. If different, it is assumed the line_arrangement of the underground cable is unknown". But I'm still not confortable with this tagging scheme. First, what about edge cases ? Imagine a 100 km underground cable, someone adds the line_arrangement=* for the first 10 km, someone else at the last 10 km. If the tag at the node at km10 and at km90 is the same, it will imply the line arrangment from km 10 to 90, though it should be unknown. Second, won't it be too difficult to find the first mapped node if he's on another osm way ? I would strongly prefer the line_arrangement=* to be on way for underground cable. Babouche Verte (talk) 10:55, 1 June 2023 (UTC)

I've updated slightly the proposal, underground and interpretation sections mainly. It's now recommended to set arrangement on joining nodes and data consumers should consider a length threshold to solve nodes on which the arrangement is undefined.

The proposal can't define such rules as it depends on the line we qualify. Thresholds and design rules aren't the same over a high voltage cable and telecommunication overhead line. I know it's not satisfying for now, but it's the most versatile framework we can provide from this perspective. Fanfouer (talk) 17:23, 2 June 2023 (UTC)