Home » railML newsgroups » railml.infrastructure » [railML2] Clearer modelling of the signal designation
[railML2] Clearer modelling of the signal designation [message #2320] Sat, 25 January 2020 14:50
Tobias Bregulla is currently offline  Tobias Bregulla
Messages: 20
Registered: June 2017
Junior Member
Good afternoon,

we want to extend our infrastructure export from GPSinfradat by the
signal designation (unique identifier of a signal per operating point).
In doing so, I noticed a contradiction between the railML rules and the
example on the corresponding Wiki page.

According to the wiki entry for the signals (see
https://wiki2.railml.org/index.php?title=IS:signal), the general rules
for @code (machine-readable designation for exchange) and @name
(established human-readable designation) also apply there. In the
example for the signal, however, the designation is given at @name,
which in my opinion is not correct and hinders the data exchange.

For explanation: it is about the designation "20ZS3" attached to this
German combination signal
( https://upload.wikimedia.org/wikipedia/commons/2/2e/Ks-Signa l.jpg),
which is also used in site plans and many other documents.

In our opinion, the current wiki example should be described as follows:

<signal id="sig2630123" dir="up" pos="18597" type="combined"
function="home" ruleCode="DE:ESO:HV"
code="A1" name="ESig A1"
description="Einfahrsignal des Bf Boppard" xml:lang=de
ocpStationRef="KBOP" absPos="109647">
<geoCoord coord="50.237850 7.576116"

In this example, the designation "ESig A1" could be logically formed
(not mandatory, only as a suggestion) from the function function="home"
--> entry and type="combined" --> main signal in a project-specific way.

What does the community think about this? Could the example be adapted
according to this usage?

Best regards,
Tobias Bregulla
Bahnkonzept Dresden/Germany
Previous Topic: Stopping Place use cases
Next Topic: the use of @dir in railML.
Goto Forum:

Current Time: Sat Feb 22 00:58:46 CET 2020