Talk:OpenRailwayMap/Tagging in the United Kingdom

Spaces in signal numbers

I'm looking for some consensus for mapping the signal numbers: should the signal box prefix code and the signal number be separated by a space or not? Mappers are currently doing both. So far I've been mapping signals without a space. For reference, in the open data released by Network Rail (i.e. Train Planning Network Model) the signals have been named like SIG: HM366, without a space. --Jplahti (talk) 20:25, 22 October 2025 (UTC)

Stop board "inscription"

Hi Fgjgdrou! You recently added the tagging for stop boards with the :inscription subkey used for the instructions on the sign. This subkey is not used for any other railway signal in OSM. I think the well-established :caption subkey (documented at Tag:railway=signal#List of signal properties) would also be suitable, i.e. railway:signal:stop:caption. What do you think about changing this? --Entbert (talk) 23:50, 7 January 2026 (UTC)

Ah, I think I forgot about that, would probably be a better subkey to use. My only concern with it would be that we use ref=* to record the signal number, and a data consumer will use :caption instead thinking that it is the signal number. Perhaps the best approach would be to document the use of ref=* to tag signal numbers and make sure OpenRailwayMap-vector has the right behaviour in that regard for GB. If that sounds good then I'll change it on the wiki page (or you can), and change the tagging on the map likewise, and making a GitHub issue if required. --Fgjgdrou (talk) 00:23, 8 January 2026 (UTC)

I have just noticed that the top-level description of signal tagging does specify that [ref=* is used for signal number], so I will make that change. Thanks for raising this Entbert! --Fgjgdrou (talk)

Resolved: tagging changed --Entbert (talk) 16:45, 26 January 2026 (UTC)

Speed units

The section about the speed signals should clarify whether or not the value of railway:signal:speed_limit:speed=* (and railway:signal:speed_limit_distant:speed=*) should include the unit, i.e. 50 or 50 mph. Currently, both are in use. Personally, I strongly prefer the value with units for consistency with the maxspeed=* of the tracks. --Entbert (talk) 00:28, 20 January 2026 (UTC)

@Fgjgdrou: You created most of the nodes without units. Would you mind if we add the units? --Entbert (talk) 16:37, 29 January 2026 (UTC)

Sorry for forgetting about getting to this. I don't have any objections either way, whilst we could have a local default given the isolated nature of GB, equally the transition to ERTMS (specifically ETCS, rather than GSM-R), and thus the metrication of speed limits, such as on the Cambrian Line, would change this default over some time, even though it may not be implemented across the whole of the GB rail network.

I think that the best solution to this potential future problem would be tagging speed signs with their units if applicable per the global default. I would be fine with amending this for all of the UK speed signs. Fgjgdrou (talk) 21:03, 1 February 2026 (UTC)

I have now added a note on the use of units in accordance with Map features/Units. Maybe the unit should explicitly be stated for metric signs as well (despite being the default) to distinguish genuine metric signs from cases with wrong tagging? Feel free to change it as you see fit. --Entbert (talk) 16:26, 3 February 2026 (UTC)

Design vs shape

The main and junction signals use a subkey :design to differentiate combined/individual main signals and feather/theatre junction signals. This subkey is used almost nowhere outside the UK. (Only in 2 cities, with undocumented tagging in both cases as far as I can tell.) I think the :shape subkey documented at Tag:railway=signal#List of signal properties ("used to distinguish signals that are visually distinct, but have otherwise identical tagging") would have been a better choice. It may be too late to change it now, but other signals added to the tagging scheme should probably use :shape. --Entbert (talk) 17:04, 26 January 2026 (UTC)

Banner Signal States

Hello Entbert, I noticed that you added suggested tagging for GB banner repeater states. In the UK, by the nature of a banner repeater, they always have 2 states, On, and Off by definition. Only some banner repeaters have a green 'Clear' state. What would you say about amending the suggested tagging to differentiate between if there is a 'Clear' state or not? Fgjgdrou (talk) 21:08, 1 February 2026 (UTC)

Simply listing all possible aspects seems the most natural to me (and is the way we do it in Germany). But I wouldn't mind if you do it differently here. I read at [1] though that there are banner signals which don't have a "white off" aspect. These would not be distinguishable with something like :clear_state=yes/no. --Entbert (talk) 21:26, 2 February 2026 (UTC)