Add line_management to power support presets

[francois.lacombe]

Dear maintainers,

The key line_management has been very recently reviewed on the wiki and received an approval vote.
​osmwiki:Key:line_management
It allows to better describe all power supports and remove any use tower:type or pole:type

The post-vote cleanup is in progress and documentation is currently under completion.
It may be great to update JOSM presets as follow :

• Add the key with its seven values (straight, branch, split, cross, transpose, transition and termination) on power supports presets power=tower, power=pole, power=insulator, power=portal and power=terminal
• Warn about tower:type or pole:type on any power support object since no value remains recommended with them. Encourage replacement as follows : ​https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management#Values_to_be_replaced
• Warn about the use of line_management on any other feature than a node.

Feel free to ask for any unclear point, all the best

François

[skyper]

Are multiple values allowed? e.g. branch;transpose.

Note: JOSM does not well support the additional separator |, so far.

[simon04]

​https://taginfo.openstreetmap.org/keys/?key=line_management → 659 usages

[skyper]

Replying to skyper:

Are multiple values allowed? e.g. branch;transpose.

Sorry, this example is in complete, I meant: line_management=branch;transpose|straight

Note: JOSM does not well support the additional separator |, so far.

In this case, we are talking about a node which has not left/right side. It might be better to use direction like: line_management:NW=branch;transpose plus line_management:SE=straight.

[anonymous]

Hi @skyper

This key is mainly intended for single values but complex situations may exists encouraging us to combine some of the 7 values in a matrix (not in a ; list)
| and () define a table with columns and rows. I drafted a page explaining this, conform to highway's lanes usage: ​https://wiki.openstreetmap.org/wiki/Matrix_values
​https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management#Level_composition_matrix

It's the same as line_attachment.

Anyway, line_management=branch;transpose|straight, combining | and ; can't exist.

:NW, :SE... option are interesting but weren't proposed. I'm ok to give it a try, do you have past examples on which it has been done this way?

[skyper]

Replying to anonymous:

Hi @skyper

This key is mainly intended for single values but complex situations may exists encouraging us to combine some of the 7 values in a matrix (not in a ; list)
| and () define a table with columns and rows. I drafted a page explaining this, conform to highway's lanes usage: ​https://wiki.openstreetmap.org/wiki/Matrix_values
​https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management#Level_composition_matrix

It's the same as line_attachment.

Anyway, line_management=branch;transpose|straight, combining | and ; can't exist.

The difference is a <combo box> vs. a <multiselect> and which separator. Above looks like a <multiselect> with | as separator. In my understanding this means you might have several lines but for each line only one value is possible at that point (node).

:NW, :SE... option are interesting but weren't proposed. I'm ok to give it a try, do you have past examples on which it has been done this way?

Usually [:]direction is used in the key and the cardinals are in the value. In your case, I would restrict to only use two letter abbreviations and estimations but I am sorry, I have no existing tag which is somewhat in use. The problem exists e.g. if you have a city_limit sign with names on both sides.

[francois.lacombe]

Replying to skyper:

The difference is a <combo box> vs. a <multiselect> and which separator. Above looks like a <multiselect> with | as separator. In my understanding this means you might have several lines but for each line only one value is possible at that point (node).

Understood.
Let's focus on 7 simple values for now, just like line_attachment case: a combo box will do the job.
Matrix values, composed situations will come later (knowledgeable people are expected to type it manually).

Usually [:]direction is used in the key and the cardinals are in the value. In your case, I would restrict to only use two letter abbreviations and estimations but I am sorry, I have no existing tag which is somewhat in use. The problem exists e.g. if you have a city_limit sign with names on both sides.

Got it, thank you
Due to recent vote it should be tested prior to be documented.
I think it's a decent way of doing for many POI in OSM. I'll see to integrate to further refinement on poles (a third stage proposal is already drafted and will be voted by the end of 2020).

[francois.lacombe]

Hi guys

Are the 7 simple values acceptable for you to begin with?
They are similar to what is done on line_attachment preset #17984

Adding them to presets will allow to speed up the cleaning of corresponding tower:type values

:direction alternative still waiting to be evaluated and shouldn't block simple values integration

All the best

[Klumbumbus]

In 17263/josm:

see #19383 - Add line_management to power support presets, warn about line_management on ways, deprecate pole:type and power related tower:type values

[Klumbumbus]

What happens with tower:type=transition and pole:type=transition? They are not in the table at ​https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management#Values_to_be_replaced

[francois.lacombe]

You're right I forgot them two, thank you to remind me this
They weren't described in the wiki and they're replaced by location:transition=yes (eventually with line_management=transition, if and only if it's not a split or a branch)
​https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management#Transition_supports_aren.27t_terminations

All the best

[Klumbumbus]

So do you think it is safe to enable the fix button to replace these two tags by location:transition=yes or should the fix button be disabled?

[francois.lacombe]

It's ok to replace tower:type=transition and pole:type=transition by location:transition=yes 100% of times.
But there is also a risk to miss line_management=transition when applicable and fix button can't know when actually

Up to you, depending on what you use to do in such situations

[Klumbumbus]

In 17284/josm:

see #19383 - Deprecate tower:type=transition and pole:type=transition in favor of location:transition=yes

[francois.lacombe]

Thank you guys, as always it's great :)

[Don-vip]

Milestone renamed