Home » railML newsgroups » railML.infrastructure » [railML3] Texts on boards
[railML3] Texts on boards [message #3746] Mon, 13 October 2025 10:57 Go to next message
Dominik Looser is currently offline  Dominik Looser
Messages: 39
Registered: March 2020
Member
Dear all,

In our software railOscope, we have the possibility to define a "board text" attribute for boards. This is the text that is physically written on boards that are exported as <signalIS> (and signalIL) in railML3.x.
We currently have no way of exporting this "board text" attribute but our customer needs to transfer this information via railML.
Therefore we suggest a new attribute for <signalIS> or <signalIS>/<signalConstruction> in railML 3.4.
It's important to consider that these board texts can contain several lines so the exact modelling in railML is not clear to me.

If examples are needed, maybe Bane NOR can provide them.

Best regards,
Dominik Looser
trafIT solutions
Re: [railML3] Texts on boards [message #3762 is a reply to message #3746] Fri, 24 October 2025 10:30 Go to previous messageGo to next message
Terje Nordal is currently offline  Terje Nordal
Messages: 21
Registered: December 2023
Junior Member
Dear all,

I can confirm, on behalf of Bane NOR, that this is something we are interested in modelling as part of railML.

Some examples of where we would benefit from this possibility:
- "Word area boards" (boards that inform about the borders and extents of our defined work areas), see attachment "WA board example.png", where the text "Arbeidsområde" (meaning work area) is fixed, while the "OSL 1" and "OSL 3" are specific to that one board.
- "ID boards" (information boards for various other signals and board, informing about things such as the name and location of that specific board), see attachment "ID board example", where each line of text in that board is specific to that one board.

Best regards
Terje Nordal
Bane NOR
Re: [railML3] Texts on boards [message #3791 is a reply to message #3762] Tue, 25 November 2025 15:22 Go to previous messageGo to next message
Marharyta Vyskarka is currently offline  Marharyta Vyskarka
Messages: 23
Registered: April 2025
Junior Member
Dear all,

I am answering on behalf of Christian. At first I would like to mention that the value/meaning of the element should be modeled in unified way and that it cannot be replaced by the text or it's representation. It could be provided as additional information, but for that I would like to clarify, what is the meaning behind the given examples and how can we read/interpret it? And are there any other example where representation or information layout is important?

Best regards,
Marharyta Vyskarka


Marharyta Vyskarka – Software Developer
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Texts on boards [message #3807 is a reply to message #3791] Wed, 03 December 2025 10:14 Go to previous messageGo to next message
Terje Nordal is currently offline  Terje Nordal
Messages: 21
Registered: December 2023
Junior Member
Dear Marharyta,

The goal of our given examples was to show a few different cases of boards in Bane NOR's system where we define specific text to be put on boards. There could be 1, 2, 3... lines of text, and the text could be of different length. Our thinking is that the possible "text on board" parameters would only convey what the contents of that text would be. Any other specifics to the different boards should already be defined by using type designators, ie. the shape and size of a board, any symbols that are shown etc. The size, font, color etc. of the different lines of text should also be part of the type designator, in such a way that the "text on board" could define strings for the different lines of text shown on the board, and the rest of the board layout would be obvious from what type designator it has.

In the examples given, the ID board text info would then be:
Text line 1: M
Text line 2: 444
Text line 3: MAG

The WA board (actually defined as two different boards in our system) information would be split between two type designators:
Text line 1 (type designator 1): Arbeidsområde
Text line 2 (type designator 1): OSL 1

Text line 1 (type designator 2): Arbeidsområde
Text line 2 (type designator 2): OSL 3

The different lines of text could either be separate parameters or one parameter with a specified separator for the different lines.

I hope this answers your inquiry.

Best regards
Terje Nordal
Re: [railML3] Texts on boards [message #3830 is a reply to message #3807] Tue, 09 December 2025 16:46 Go to previous messageGo to next message
Marharyta Vyskarka is currently offline  Marharyta Vyskarka
Messages: 23
Registered: April 2025
Junior Member
Dear Terje,

I am answering again on behalf of Christian. Thank you for the reply and providing more details. We want to know specifically which subtype of signals do you want to use for this, what would be their functionality?

Best regards,
Marharyta Vyskarka


Marharyta Vyskarka – Software Developer
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Texts on boards [message #3849 is a reply to message #3830] Wed, 17 December 2025 20:51 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 110
Registered: March 2008
Senior Member
Dear all,

@Marharyta: These boards are signals of their own, some of them attached to other signals (like Terje's M 444 MAG example, Norwegian signal code 101) and some of them not (like Terje's WA board, Norwegian signal code 105E).

@Terje: Do the ID boards have their own object ID?

Best regards,
Thomas


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Texts on boards [message #3919 is a reply to message #3849] Mon, 02 March 2026 14:45 Go to previous messageGo to next message
Terje Nordal is currently offline  Terje Nordal
Messages: 21
Registered: December 2023
Junior Member
Dear all,

@Thomas Very sorry about the late reply here. I find no traces of our ID boards as their own object ID in Bane NOR's systems, neither for legacy systems or ERTMS. For the latter this may be subject to change, at least I think they should have their own ID, but so far nothing unfortunately.

Best regards
Terje

Re: [railML3] Texts on boards [message #3924 is a reply to message #3919] Sun, 08 March 2026 22:58 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 536
Registered: January 2016
Senior Member
Dear Terje,

here comes a first idea for the description of a signal layout based on your examples:

<signalIS ...>
  ... (designator, signal type, location)
  <signalLayout form="rectangle">
    <text value="M" />
    <text value="444" />
    <text value="MAG" />
  </signalLayout>
</signalIS>

Number 2:

<signalIS ...>
  ... (designator, signal type, location)
  <signalLayout form="circle">
    <text value="M" />
    <text value="444" />
    <text value="MAG" />
  </signalLayout>
</signalIS>

Number 3:

<signalIS id="sig01" ...>
  ... (signal type, location)
</signalIS>
<signalIS id="sig01a" belongsToParent="sig01" ...>
  ... (designator)
  <signalLayout form="rectangle">
    <text value="Arbeidsområde" />
    <text value="OSL 1" />
  </signalLayout>
</signalIS>
<signalIS id="sig01b" belongsToParent="sig01" ...>
  ... (designator)
  <signalLayout form="rectangle">
    <text value="Arbeidsområde" />
    <text value="OSL 3" />
  </signalLayout>
</signalIS>

What do you think: Does this go into a good direction? Any feedback is highly appreciated...

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Texts on boards [message #3927 is a reply to message #3924] Mon, 09 March 2026 10:57 Go to previous messageGo to next message
Terje Nordal is currently offline  Terje Nordal
Messages: 21
Registered: December 2023
Junior Member
Dear Christian,

I appreciate the work done here. As was discussed in todays workshop 32, we have some feedback from Bane NOR. I am also adding some additional comments that were mentioned from other parties during the meeting.

1. The suggested modelling contains information on the shapes of the boards (and things such as colors, font and font size were also mentioned in the meeting). Bane NOR thinks such things should rather be part of the type designator of the signal (my impression from the "thumbs up" from Martin Zien (Siemens) in the meeting is that they agree). The use case we want to cover by the "Texts on boards" is to add information that is not obvious from the type of signal, typically things that are specific to that unique board. The location specific text content is the only information we know about for this at the moment, however, we would not rule out possible additions to this in the future.

2. From the code examples above it is not obvious which text line on the specific board each "text value" belongs to. Should that information maybe be explicit in the railML modelling?

3. There was also a discussion whether the language of the written text should be part of the modelling. In our opinion this is not needed, as we are only talking about specific content written on a board. If railML.org has a different opinion, I think we will be able to cope either way.

Best regards
Terje

Re: [railML3] Texts on boards [message #3928 is a reply to message #3924] Mon, 09 March 2026 11:06 Go to previous messageGo to next message
Mathias Vanden Auweele is currently offline  Mathias Vanden Auweele
Messages: 100
Registered: February 2025
Location: Brussels
Senior Member
Today at the railML vs BaneNOR meeting, I raised the idea of having the possibility to add an svg to describe the board layout. That would allow all possible things to be added (arrows, text, illustrations, ...) in all kinds of order or orientation with all kinds of fonts, sizes and so on.

If it's only about the graphical information and nothing needs to be extracted then this would fill the use case (for example for a track layouter). Additionally SVG support parameters/variables so this is actually also a very future proof way of working, incase a templated approach would be taken.

Here's an example of SVG code for the two attachments of Terje

The round board:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 200 200" width="200" height="200">
  <circle cx="100" cy="100" r="96" fill="white" stroke="black" stroke-width="4"/>
  <text x="100" y="60" text-anchor="middle" dominant-baseline="central" font-family="Arial Black, Arial, sans-serif" font-weight="900" font-size="40" fill="black">M</text>
  <text x="100" y="100" text-anchor="middle" dominant-baseline="central" font-family="Arial Black, Arial, sans-serif" font-weight="900" font-size="40" fill="black">444</text>
  <text x="100" y="140" text-anchor="middle" dominant-baseline="central" font-family="Arial Black, Arial, sans-serif" font-weight="900" font-size="40" fill="black">MAG</text>
</svg>

The rectangle board:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 360 200" width="360" height="200">
  <rect x="3" y="3" width="354" height="194" fill="white" stroke="black" stroke-width="4"/>
  <text x="180" y="56" text-anchor="middle" dominant-baseline="central" font-family="Arial Black, Arial, sans-serif" font-weight="900" font-size="48" fill="black">M</text>
  <text x="180" y="103" text-anchor="middle" dominant-baseline="central" font-family="Arial Black, Arial, sans-serif" font-weight="900" font-size="48" fill="black">444</text>
  <text x="180" y="150" text-anchor="middle" dominant-baseline="central" font-family="Arial Black, Arial, sans-serif" font-weight="900" font-size="48" fill="black">MAG</text>
</svg>

For general reference: an SVG is "Scalable Vector Graphics" and as you can see above, allows to define very simple but also very complex graphics in code, based on vectors. The 'Scalable' part means that you can scale this to something very big and something very small. There are no pixels that need to be scaled, it's first the vector that is scaled and then the pixels are calculated. That's why it's used a lot for web.

In my opinion, svg's would make the most sense here. It's also an extensive of the XML data format


Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium

[Updated on: Mon, 09 March 2026 12:37]

Report message to a moderator

Re: [railML3] Texts on boards [message #3932 is a reply to message #3928] Mon, 09 March 2026 13:39 Go to previous messageGo to next message
Dominik Looser is currently offline  Dominik Looser
Messages: 39
Registered: March 2020
Member
Dear all,

We use SVG to render all the signal icons in our tool so we could easily export it. However, this would bloat up the files even more, especially since some signal icons are quite complicated to render. The rendering is also always the same per typeDesignator, expect for the texts. So defining the texts for each <signalIS>-instance is sufficient.
If we want to define the rendering for each typeDesignator, I think we should use a similar structure as with the specificInfrastructureManagers in IL (but in IS instead), define the rendering of a typeDesignator once and then reference it from <signalIS>/<signalLayout>. But we should only go there if there is a specific need for it.
I would appreciate if we could have a @sequence attribute for each <text>-subelement, which is iirc also a principle that we voted on during a railML-conference.

Best regards,
Dominik Looser
trafIT solutions gmbh
Re: [railML3] Texts on boards [message #3933 is a reply to message #3932] Mon, 09 March 2026 15:37 Go to previous message
Mathias Vanden Auweele is currently offline  Mathias Vanden Auweele
Messages: 100
Registered: February 2025
Location: Brussels
Senior Member
@Dominik, yes we discussed the additional of @sequence and that was something that everyone was behind.

An idea building on what you said, having:
1. a general way of defining the svg template for a type linked to a TypeDesignator
2. the svg contains parameters
3. those parameters are completed in the entities <text> elements


Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
Previous Topic: Turntable and Transfer table
Goto Forum:
  


Current Time: Tue Mar 10 10:31:02 CET 2026