Proposal talk:Catenary mast details

Structure

Hello, first of all I support your proposal and it's a good opportunity to improve things about catenary masts. I have a few points to make about current practices regarding power supports tagging. We have great time to refine existing tagging and it would be useful for your proposal.
How do you feel about considering using structure=* for masts structure instead of catenary_mast:construction=* or tower:construction=*? The first is way more used and versatile than the two lasts. Fanfouer (talk) 18:00, 4 January 2025 (UTC)

Resolved: I'm fine using the existing tag structure. I updated the porposal. --reDoubleYou 14:54, 10 January 2025 (UTC)

Usage of catenary_mast namespace

In my opinion, catenary_mast namespace proposed for most keys of the proposal is not always relevant and will prevent to reuse useful ontology on other topics despite relevant.
For instance catenary_mast:insulator=* intended for describing insulators' material is too specific as we already have power=insulator, among other comments about this particular key.
This proposal should reuse, and possibly complete, what is already existing instead of providing too specific keys with a namespace. Fanfouer (talk) 18:00, 4 January 2025 (UTC)

Resolved: I agree with you. I already cleaned the proposal a little from namespace and will continue later on. --reDoubleYou 15:27, 10 January 2025 (UTC)

insulators

I cleaned the proposal from namespaces as much as possible now. (About catenary_mast:suspension and catenary_mast:midpoint_anchor we need more discussion - see other points.)
I'm struggeling with the tag for the insulators. power=insulator cannot be used at the catenary mast as the key power is already used for power=catenary_mast. Values for a key insulator aren't defined yet. material is used to describe the structure of the catenary mast. I agree that it isn't necessarry to tag the insulator at the catenary mast for the support-types head_span, portal, end/anchor, tensioning_only as we could propose to map head_spans and portals directly and place the insulators on them or on the over head contact line at anchors i. e. But I'd like to avoid to map single cantilevers. They contain often multiple insulators. So the information would be good to have on the of the catenary mast for the support-types cantilever and lateral I think. For that we need a new tag. Maybe we could introduce insulator=* with the material as value (usable for all insulators as well). What do you think? --reDoubleYou 21:55, 10 January 2025 (UTC)

insulator=*_loop should be separated into insulator=loop + material=*

There are many actual forms of them Insulator_(electricity)#Types

I don't know about whether insulator=*_cantilever has other structures. I would consider using insulator=structure to mean the supporting structure is used for insulation.

—— Kovposch (talk) 10:15, 15 January 2025 (UTC)

You already had insulation:material=* , so I wonder how insulator=* should be used Proposal:Insulation proposal
—— Kovposch (talk) 10:09, 15 January 2025 (UTC)

I thought for some time about the topic. For now I think, the best option is to narrow down the topic of insulators to catenary masts with cantilevers. At all other types (head span, portals, end, tensioning only, lateral) the insulators are mounted directly at or in the structure we could map, so we could map the insulators by itself directly (power=insulator). AS I said, I'd like to avoid mapping cantilevers, I would suggest to map the insulators just for - and in this case directly on the - catenary masts with cantilevers.

So we can discuss how to do that. I like your suggestion to devide into type and material. As material=* is already used to describe the material of the catenary mast, I'd like to adapt the considered tagging insulation:material=*. So we could have the following tagging to describe insulators between the overhead contact line and grounded catenary mast as a first suggestion:

Feature	Key	Value	Description	Photos
insulator structure	insulator	loop	sling insulators, no shields at the surface, often used for light rail systems and grp as material
		shielded_loop	sling insulators, with shields at the surface, often used for light rail systems and composite as material
		post	sling insulators, with shields at the surface - I think this is the most used for heavy rail systems
		structure cantilever	the cantilever itself takes the role of insulation too by consisting of an insulating material
insulator material	insulation:material	glass	for insulators made of glass
		ceramic	for insulators made of ceramic
		porcelain	for insulators made of porcelain
		composite	for insulators made of composite material
		grp	for insulators made of glass fibre reinforced plastic

this tagging could be used as base for a general insulator tagging (plus extended tagging for all other usecases - this is just for cantilevers on catenary masts).
--reDoubleYou 22:56, 17 January 2025 (UTC)

Am not sure how insulation:material=* is supposed to be used. Will wait for @Fanfouer: to decide. But now I guess it is supposed to be used for the feature itself, eg power=line , railway=rail , or the power=catenary_mast here. So insulator:material=* may be the correct choice, and to follow insulator=* itself.

—— Kovposch (talk) 09:39, 18 January 2025 (UTC)

Hello all. Well it's great to see how this proposal improves. It's ok for insulator=* key, here is a few thoughts about proposed values: insulator=structure should be moved to insulator=cantilever since structure is too vague. We would add as much values as needed in case of any other supporting insulated structure.

I changed it. Yor're right, we could add more, if needed --reDoubleYou 15:17, 21 January 2025 (UTC)

How should be mapped strain insulators used for anchorage, like this one (although used for feeder line)?

maybe post could fit? I'm not an expert in this topic to say what are the differences of post to this one. But I think it's not absolutely necessary to find a solution to that in this proposal. --reDoubleYou 15:27, 21 January 2025 (UTC)

Finding a solution to describe cantilevers would be very useful for power distribution grids as well.

I'm still not certain that insulation:material=* is completely suitable as this for insulator=cantilever. Anyone could understand it as the material that insulates the cantilever (e.g a piece of conducting metal rod under a plastic cover). Once this solved, it could work yes, great reuse of unfinished work years ago Fanfouer (talk) 12:40, 19 January 2025 (UTC)

I'm not sure that I've got your point. By tagging insulator=cantilever I say, the cantilever is the thing, that insulates. Giving now insulation:material=* it's clear, that it referes to the cantilever itself. What do you mean with your example? I'm not 100% sure but I think grp is the only material used for this. --reDoubleYou 15:38, 21 January 2025 (UTC)

Attachments and lines management

line_attachment=* and line_management=* had previously been introduced to refine existing tagging for power towers.
From that perspective, catenary_mast:suspension=* confuses anchor and suspension. Suspension can't be suitable for end value (as example picture shows an anchor, not a suspension).
Thus I suggest to establish how existing keys could be suitable for particular case of catenary mast and propose required new values to do so if necessary, instead of creating a particular key for that here.

We do need further work to give more details about anchor and suspension and I be glad to contribute to that. Fanfouer (talk) 18:00, 4 January 2025 (UTC)

I see choosing the tag catenary_mast:suspension confuses. Suspension is the wrong term as I understand now. The tag I'd like to propose doesn't mean how the over head contact line is attached to the pole but what type of construction is supported by the catenary mast that supports the over head contact line. So would you agree using instead support as key? Except for the value end I think the values fit. Instead of support=end maybe support=anchor would fit better? As reminder: For the moment this proposal aims to give catenary masts more details. It doesn't aim to say how the over head contact line is attached to the catenary mast. That for I could imagine a node on the railway-line with this information. But it would be useless as it is always line_attachment=suspension (except the case a over head contact line end at a catenary mast). On electric railways we have the situation in contrast to power towers that the over head contact line is mapped at another place as the catenary mast. So as I'm writing this I think that line_attachment doesn't belong to electric railways, especially catenary masts. --reDoubleYou 16:02, 10 January 2025 (UTC)

I added line_management=* to the proposal at the section further tags (not new, but proposed to be used) --reDoubleYou 20:24, 10 January 2025 (UTC)

Thinking about support=* I'm not happy at all as this tag is used to describe how the mapped item (in this case the catenary mast) is supported (see Wiki . But the key needs to describe, what type of support of the over head contact line is supported by tha catenary mast. So we need a key with the swopped meaning.

• I thought about function=* but this key ins't documented and values are wild looking at taginfo.
• maybe supporting=* to declare, what is supported by the mapped item?
• or catenary_mast:function=*?

--reDoubleYou 23:26, 17 January 2025 (UTC)

These are valid points. I'm fine to give details about the structure used to support the contact_line as I've imagined a similar strategy for power grids. I bet we could refine catenary_mast:suspension=* with several keys, as follows:

• catenary_mast:suspension=cantilever => line_attachment=suspension + suspension=cantilever
• catenary_mast:suspension=head_span => Should be mapped as a way between two or more masts, let's imagine, power=head_span (or power=portal + structure=head_span) with intermediary nodes to describe structures actually supporting contact lines (with line_attachment=suspension + whatever describing goose necks or insulators)
• catenary_mast:suspension=portal => Same as head_span with power=portal on the way
• catenary_mast:suspension=anchor => line_attachment=anchor + line_management=termination
• catenary_mast:suspension=tensioning_only => I'm not sure of the difference with anchor value. Does it refers to tensioning while the line continues afterwards?
• catenary_mast:suspension=lateral => It's a particular case of line_attachment=suspension we also find on power grids (see inclined insulators), so line_attachment=suspension + suspension=lateral?

I don't think it's the same. lateral just brings lateral forces in. The power mast you show in the link does also bring essential vertical forces in, the catenary mast with lateral doesn't. So these are different types. --reDoubleYou 21:02, 21 January 2025 (UTC)

suspension=* could be better named, like suspension_attachment=* for instance Fanfouer (talk) 13:15, 19 January 2025 (UTC)

Thanks for the suggestions. But I think reusing line_attachment=* and line_management=* will bring us in trouble if the catenary mast supports as well feeder lines and so on. I think we should keep these tags for this case it also works as power pole. Then we could easy reuse the known tagging. --reDoubleYou 21:02, 21 January 2025 (UTC)

I like your point to set a node on the over head contact line to describe the attachment and further information. But I'd like to exclude this from the present proposal and bring it into another. There are more things to bring in... --reDoubleYou 21:02, 21 January 2025 (UTC)

To clarify the difference between anchor and tensioning_only:

* anchor: these catenary masts take the tension from the over head contact line in position over the track. So a loco could (theoretically!) move with the pantograph until the end of the line.

* tensioning_only: these catenary masts do the same like anchor, but not in position above the track, the over head contact line is first led out of the track and ends (somwhere) at the catenary mast.

So how to continue? I think we need a new tag todescribe the surveyed information. It is valuable information! I like supporting=* most at the moment. I agree with you to map the head span and portal seperately as way, definitly (--> new proposal will come). --reDoubleYou 21:02, 21 January 2025 (UTC)

You still had better to rename catenary_mast:suspension=* to catenary_mast:attachment=* or catenary_mast:contact_line_bound=* and if the point is to document how contact line is bound to mast, values like head_span and portal are out the scope (cantilevers or anchors are bound to portals). How should we handle single masts that both tension one section and suspend another with a cantilever? Fanfouer (talk) 08:43, 28 January 2025 (UTC)

Resolved: I clearified the situation for myself and divided between two things: 1.: the catenary mast supports a structure, to that the i. e. over head contact line is bound and 2.: the over head contact line is attached directly to the catenary mast. These are two different things we need to describe by two different tags. So I changed the tagging in the proposal to the keys catenary_mast:supporting=* and catenary_mast:attachment=*. --reDoubleYou 21:13, 13 February 2025 (UTC)

It's way better, thank you! Fanfouer (talk) 22:25, 18 February 2025 (UTC)

Midpoints anchors

We also find such constructions for power lines. In my opinion, such should be mapped as a way along the supporting rope, connected to contact lines with power=insulator help, just like power=portal mapped as ways. It doesn't require to be a property of a node.
power=portal is already used for catenary supports on railways in France, for instance here here Fanfouer (talk) 18:00, 4 January 2025 (UTC)

First of all to clearify that we are talking of the same I added a picture showing a scheme of the ropes that form the midpoint anchor. At the midpoint anchor the over head contact line cannot move along or lateral (but just a little vertical).

Scheme of midpoint anchor at an over head contact line

If I understand you right, you'd like to not map something like catenary_mast:midpoint_anchor=yes at the catenary mast but you'd like to map the blue ropes as way from the mast to the midpoint anchor. Am I understanding you right? If so, I'd be fine doing that. But I'd like to exclude it from this proposal and take it into another I'm preparing with more stuff refering to over head contact lines (friendly reminder: this proposal is about catenary masts). Within this way one could place a to map a power=insulator. --reDoubleYou 20:32, 14 January 2025 (UTC)

Yes, I'd prefer mapping it with several objects to follow the blue rope on your scheme. It's fine to exclude it from this proposal and discuss it further in another one Fanfouer (talk) 13:17, 19 January 2025 (UTC)

:

Resolved: I deleted the part with catenary_mast:midpoint_anchor=yes from the proposal as we plan to include it into another proposal as property of a in the over head contact line.

"other"

I can see where you're coming from, but many structure=others become invalid when a new type of construction is added to the list on the wiki. —M!dgard (talk) 22:04, 14 January 2025 (UTC)

Resolved: Good point. I removed the tag structure=other as of your hint. The information of structure=other and no tagged structure is almost the same (I'd just know, that it's none of the other documented, but now wich one concrete) and we avoid creating your described situation.

Usefulness

I cannot imagine any use for this data. As you write, it is easy to survey, but there are many, many catenary masts and surveying them is a huge undertaking (guy wires, which type of tensioning system, switches, etc. can often not be seen reliably on aerial imagery).

Could you provide examples of the valuable analyses that you wrote this data would allow? —M!dgard (talk) 22:13, 14 January 2025 (UTC)

Thanks for the question. Yes, I can!

• 2 years ago I analysed causes of short circuits in railway power supply as part of an thesis at university. The data about when and where short ciruits occured we got from the railway operator. But it was difficult to get data about the installed infrastructure (mast types, how the over head contact line is supported and especially what insulators + material is used. We git this information just for a whole track from town to town. At some point, the data could be freely available.
• I'm working as engineer in railway power supply. We often use OpenRailwayMap as map for orientation. But there are just some basic data. With these detailed data about catenary masts (and other proposals will follow) we could create new maps that simplify our daily buissness.

--reDoubleYou 20:11, 18 January 2025 (UTC)

Missing midi structure

You are missing the midi structure of catenary mast. It's very specific to the south west of France. I think the best way to tag it is construction:structure=midi. You can see an example on this link (to WikiMedia). —ymerik (talk) 19:35, 15 January 2025 (UTC)

Resolved: Thanks for the advice! I added it as structure=midi. --reDoubleYou 20:23, 18 January 2025 (UTC)

I bet midi is not a structure (like lattice, solid...) but is more a design=*, aren't you? Fanfouer (talk) 13:20, 19 January 2025 (UTC)

I think it's okay keeping this as a separate value because the mast itself differs to "normal" masts. But yes, I think we need to define a tag for a way between the two catenary masts like for portals and head spans to clearify it. --reDoubleYou 21:30, 27 January 2025 (UTC)

We need to be more precise than it differs. structure=* is about classification of assembly method while design=* is about assembly itself and architecture. Putting too specific values in structure=* will cause harm to both. Actually, midi portals are composed of bent solid iron beams which is no different from structure=h-profile. Fanfouer (talk) 08:06, 28 January 2025 (UTC)

Resolved: I deleted structure=midi from this proposal. Maybe we could propose to map it as something like power=portal + structure=midi. --reDoubleYou 21:35, 13 February 2025 (UTC)

Not "catenary" "mast" only

OpenRailwayMap/Tagging#Catenary_mast has power=catenary_portal separate from power=catenary_mast for your catenary_mast:suspension=portal now. Either it needs to be deprecated, or the appropriateness of power=catenary_mast needs to be reconsidered.

In my opinion power=catenary_portal doesn't affect the present proposal with its tag catenary_mast:suspension=portal as the proposed tag just declares a catenary mast to support a portal strucure. The portal itself (as between the two catenary masts) could be tagged as power=catenary_portal. --reDoubleYou 20:45, 18 January 2025 (UTC)

A clear choice has to be made between all those values (e.g power=portal vs power=catenary_portal) and the remaining should be discouraged/deprecated Fanfouer (talk) 13:22, 19 January 2025 (UTC)

Resolved: I agree with you. We should discuss this in another proposal. This is not part of the present one --reDoubleYou 21:05, 21 January 2025 (UTC)

Rigid overhead conductor rails

Rigid overhead conductor rail can be used above-ground near tunnels https://www.furrerfrey.ch/en/service/rigid-overhead-conductor-rail-cr4/ https://www.furrerfrey.ch/app/uploads/2024/10/FurrerFrey_Fahrleitung_DSS_SBB_Paradiso-Ticino_2-1920x1257.jpg
What should be used for them? Rename to another power=* ?
—— Kovposch (talk) 10:17, 18 January 2025 (UTC)

Resolved: The rigid over head contact rail could be mapped with the proposed tagging electrified:contact_line=rail - see Proposal:Contact line. I think catenary_mast:suspension=cantilever fits as tag for the catenary mast that supports a rigid overhead conductor rail as well. --reDoubleYou 20:45, 18 January 2025 (UTC)

Midpoint key

In the last example, I read catenary_mast:midpoint=yes but don't find any definition in the proposal body. What does this key mean? Fanfouer (talk) 13:26, 19 January 2025 (UTC)

Resolved: It was a mistake and should be catenary_mast:midpoint_anchor=yes. But that tag was excluded from this proposal recently (see discussion on topic "Midpoints anchors"). --reDoubleYou 15:52, 21 January 2025 (UTC)

Portability

portable=* was invented by iD without significant discussion Key:portable
*:portable=* is used for hand-portable in ramp:portable=*
I wanted cycle_barrier:installation=* to be a generic installation=* , but this didn't exactly get voted. In any case, I used *=free to mean it's freely placed, supported by its own weight, without being fastened/mounted.
—— Kovposch (talk) 10:00, 20 January 2025 (UTC)

I'd be fine using catenary_mast:portable=yes. I think it's clear that catenary masts aren't hand-portable :) --reDoubleYou 16:01, 21 January 2025 (UTC)

Resolved: I added it to the proposal --reDoubleYou 21:25, 27 January 2025 (UTC)

Spun_concrete structure

The tag structure=spun_conrete is mixing structure and material=*. It should be structure=spun + material=concrete as spuns could be obtained from metal or epoxy composite as well. Fanfouer (talk) 08:24, 28 January 2025 (UTC)

Resolved: You're right, I generalised the tagging following your suggestions. --reDoubleYou 21:12, 13 February 2025 (UTC)

Composite insulators

There is possible confusion about composite insulators and we should get back to actual material. This values probably considers silicone+epoxy insulators but glass+metal or grp are also composite. Then composite and composite_loop should be moved to silicone to be consistent with other values Fanfouer (talk) 08:24, 28 January 2025 (UTC)

Resolved: I changed it, thanks! --reDoubleYou 21:27, 13 February 2025 (UTC)

Tensioning direction

If proposed tansioning_direction=* relies on direction=* values and logic, it should be moved to tensioning:direction=* Fanfouer (talk) 10:05, 28 January 2025 (UTC)

Resolved: I deleted the tag tansioning_direction=* as I prefer to solve the problem by proposing to map the tensioned contact line (that leaves the track and leads to the catenary mast) itself. This way it is clear, which direction as the tensioned contact line is mapped. --reDoubleYou 21:12, 13 February 2025 (UTC)

Switches drive

Sorry for coming late on the matter. To me it's not necessary to introduce switch:drive=* as we already got actuator=* for many other features. switch:actuator=* could be optional in case of confusion on the same catenary mast with other actionable features.
Note that actuator=manual can be combined with handle=* to describe the handle shape too. Fanfouer (talk) 22:54, 18 February 2025 (UTC)

Resolved: Thanks for adding this valuable information about the existing tag. I replaced mine proposed. --reDoubleYou 21:19, 2 March 2025 (UTC)

catenary_mast:feeder

Hi. I would like to propose the following tag
catenary_mast:feeder=yes/no/isolated
Presence of overhead ‘feeder’ cable = yes as bare conductor / absent / yes as insulated conductor Crochet.david (talk) 16:13, 20 February 2025 (UTC)

I think it's on another proposal scope that is also discussed: Fanfouer (talk) 16:20, 20 February 2025 (UTC)

Resolved: This is not a property of catenary masts but of the track in osm as it contains the information about the electrification. So talk is right, linking the proposal about it. --reDoubleYou 20:57, 2 March 2025 (UTC)

catenary_mast:contact_wire

Hi. I would like to propose the following tag
catenary_mast:contact_wire=[number]
Number of conductors potentially in contact with the pantograph Crochet.david (talk) 16:13, 20 February 2025 (UTC)

I think it's on another proposal scope that is also discussed: Fanfouer (talk) 16:20, 20 February 2025 (UTC)

Resolved: This is not a property of catenary masts but of the track in osm as it contains the information about the electrification. So talk is right, linking the proposal about it. --reDoubleYou 20:57, 2 March 2025 (UTC)

railway:power_supply

Would it be possible to get rid of this tag railway=power_supply as part of this proposal, as it's used for two completely different things, being power=outlet and a catenary mast using location:transition=yes ? --Rokolell (talk) 17:15, 9 March 2025 (UTC)