Home » railML newsgroups » railML.infrastructure » [railML3] Texts on boards
| [railML3] Texts on boards [message #3746] |
Mon, 13 October 2025 10:57  |
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   |
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   |
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   |
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   |
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   |
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 #3924 is a reply to message #3919] |
Sun, 08 March 2026 22:58   |
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 #3928 is a reply to message #3924] |
Mon, 09 March 2026 11:06   |
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 #3933 is a reply to message #3932] |
Mon, 09 March 2026 15:37  |
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
|
|
|
|
Goto Forum:
Current Time: Tue Mar 10 10:31:02 CET 2026
|