Proposal:Tag:railway=balise

Tagging ETCS balises
Proposal status:	Draft (under way)
Proposed by:	Thisik
Tagging:	railway=balise
Applies to:	node
Definition:	Track-mounted transponder used in ETCS and similar train control systems
Statistics:
Draft started:	2026-05-13

Proposal

An example of Eurobasile

This proposal introduces a tagging scheme for mapping ETCS balises (Eurobalises) on railway tracks in OpenStreetMap.

Balises are fixed transponders placed on or between rails that communicate with trains as part of the European Train Control System (ETCS). They provide positioning data and transmit operational information.

The proposal defines a new primary tag:

 railway=balise

and a set of optional subtags to describe properties such as grouping, direction, and function.

Rationale

ETCS is widely deployed across Europe and continues to expand. Despite this, OpenStreetMap currently lacks a standardized way to represent balises.

Balises are:

• Physically present infrastructure elements
• Critical for train control and positioning
• Widely deployed on modern rail corridors

Mapping them would:

• Improve completeness of railway infrastructure data
• Enable advanced use cases (simulation, analysis)
• Provide a consistent alternative to ad-hoc tagging

Tagging

Primary tag

Key	Value	Description
railway	balise	A track-mounted transponder used in train control systems

Additional tags

System type

Key	Value	Description
balise:type	etcs	Balise used in the European Train Control System

Grouping

Key	Value	Description
balise:group	yes / no	Indicates whether the balise is part of a group
balise:group_id	*	Identifier for the balise group (optional)

Position

Key	Value	Description
balise:position	between_rails	Located between rails (default case)
balise:position	left_of_track	Located left of the track
balise:position	right_of_track	Located right of the track

Direction

balise:direction=* : Can simply start with direction=* unless you have other features on the same object. If so, use this tagging schema:

Key	Value	Description
balise:direction	forward	Applies to trains in forward direction
balise:direction	backward	Applies to trains in opposite direction
balise:direction	both	Applies to both directions

Function (optional)

Key	Value	Description
balise:function	reference_point	Provides position reference
balise:function	signal_data	Transmits signal-related data
balise:function	infill	Used for infill data transmission

Physical properties

Key	Value	Description
covered	yes / no	Indicates whether the balise is covered or enclosed

Mapping

How to map

• Map balises as nodes
• Place the node on a railway track (railway=rail)
• Position the node as accurately as possible

Grouped balises

Two approaches are possible:

• Map each balise individually
• Map a single node with:

 balise:group=yes

Level of detail

• Minimal: railway=balise
• Detailed: include type, direction, grouping, and function

Rendering

No specific rendering is proposed.

Renderers may choose to display balises at high zoom levels using a small symbol.

Data consumers

Potential applications include:

• Railway simulation software
• Infrastructure analysis tools
• Academic research
• Enthusiast mapping

Examples

Single balise

 railway=balise
 balise:type=etcs
 balise:group=no
 balise:direction=both

Balise group

 railway=balise
 balise:type=etcs
 balise:group=yes
 balise:group_id=12345
 balise:direction=forward

Alternatives

railway=signal

Rejected:

• Balises are not signals
• They do not provide visual indication

railway=beacon

Rejected:

• Too generic
• Not railway-specific

Compatibility

• Compatible with existing railway tagging
• Does not conflict with railway=signal or other infrastructure tags

Adoption

Suggested steps:

1. Initial use in ETCS-equipped regions
2. Community discussion and refinement
3. Gradual wider adoption

Discussion

Discussion can be find here.

Discussion may also be encouraged on the tagging mailing list and relevant community forums.

Voting

Instructions for voting

• Log in to the wiki if you are not already logged in.
• Scroll back down and click "Edit source" next to the title "Voting". Copy and paste the appropriate code from this table on its own line at the bottom of the text area:

To get this output	you type	Description
I approve this proposal.	{{vote|yes}} --~~~~	Feel free to also explain why you support the proposal!
I oppose this proposal. reason	{{vote|no}} reason --~~~~	Replace reason with your reason(s) for voting no.
I have comments but abstain from voting on this proposal. comments	{{vote|abstain}} comments --~~~~	If you don't want to vote yes or no but do have something to say. Replace comments with your comments.

Note: The ~~~~ automatically inserts your name and the current date.
For more types of votes you can cast, see Template:Vote. See also how vote outcome is processed.

• I approve this proposal. --Thisik (talk) 17:25, 27 June 2026 (UTC)
• I approve this proposal. --AwFi (talk) 08:07, 28 June 2026 (UTC)
• I oppose this proposal. 1. Not following procedure: No RfC announcement and period, voting announcements, and links. 2. 4 sections of comments not responded. Kovposch (talk) 08:34, 28 June 2026 (UTC)
• I oppose this proposal. There unresolved isues on the discussion page, othervise I would love to see a tagging schema for these objects. --Detective-fiasco (talk) 01:36, 2 July 2026 (UTC)
• I approve this proposal. --Caboulot (talk) 15:56, 5 July 2026 (UTC)
• I oppose this proposal. As far as I see this vote is meaningless as far as proposal process was concerned as RFC and announcements are missing Mateusz Konieczny (talk) 17:06, 5 July 2026 (UTC)
• I oppose this proposal. It seems that the proposal process was not followed. The proposal is extremely incomplete, even for ETCS which appears to be the focus. A more comprehensive tagging scheme that includes other data transmission devices (e.g. Crocodile, PZB magnets, ATB, ...) and provides more detailed information needs to be created. --Sikal (talk) 17:35, 5 July 2026 (UTC)
• I oppose this proposal. Incomplete proposal process, but I would still love to have something like this added :) --2tefan (talk) 05:10, 6 July 2026 (UTC)
• I oppose this proposal. Same arguments that has been already said upper. Furthermore, the tag 'balise:position' should prefer 'left' or 'right' to 'left_of_track' nor 'right_of_track' keys. The actual proposal doesn't follow the existing sheme discribing the relative position of objects compared to the OSM-way. Indeed "of_track" is useless as the referencial of "left" and "right" is the track. AurélienQ (talk) 12:45, 6 July 2026 (UTC)