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 Go to next message
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:

<track>
<ocsElements>
<signals>
...
<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"
epsgCode="urn:ogc:def:crs:EPSG::4326"/>
</signal>
...
</signals>
</ocsElements>
</track>

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
Re: [railML2] Clearer modelling of the signal designation [message #2342 is a reply to message #2320] Tue, 25 February 2020 10:21 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
Excellent suggestion!

Since there is no <designator> in railML2 except for OCPs We in Norway use @code for the designator @entry value. The register is then a fixed national register ("Banedata"). @code then forms a unique individual identifier (UID). In railML3 this will be fixed.

I would, though, suggest changing the value in your example from @code="A1" to something that resembles a UID. Since A1 probably is not unique.

I would also take the opportunity to focus this thread on the clear modelling of the board value (which is also highly applicable for railML3):

We handle the @name as described in the wiki "Established, human-readable short string, giving the object a name. Not intended for machine interpretation, please see our notice on human interpretable data fields.". So, the @name value follows no semantic constraint and is thus variable in it's semantics and not machine readable and interpretable. But we need to model the specific text on the board bellow the signal in a precise way. Shall this be done with a second signal (on the same @pos) with @switchable="false" and @name=[board text value] ("20 ZS3" in the example above). Or do we need an extension attribute @boardValue="string"?

[Updated on: Tue, 25 February 2020 11:29]

Report message to a moderator

Re: [railML2] Clearer modelling of the signal designation [message #2351 is a reply to message #2342] Wed, 26 February 2020 16:59 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 66
Registered: March 2008
Member
Dear Tobias,

I do not think that the example violates the rules. "A1" is a human-readable signal name. As Torben points out, the name does not follow any semantic constraints. Therefore, another name might be equally valid and informative to a human user. For a specific purpose, such as mirroring the text on the identification board attached to the signal post, there should be a specific modelling. I will leave the more detailed discussion to my colleague Christian.

Best,
Thomas


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Clearer modelling of the signal designation [message #2353 is a reply to message #2320] Wed, 26 February 2020 20:00 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Tobias, dear all,

Tobias Bregulla wrote on Sat, 25 January 2020 14:50

[...]
According to the wiki entry for the signals (see
https://wiki2.railml.org/index.php?title=IS:signalWink, 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.jpgWink,
which is also used in site plans and many other documents.

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

<track>
<ocsElements>
<signals>
...
<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"
epsgCode="urn:ogc:def:crs:EPSG::4326"/>
</signal>
...
</signals>
</ocsElements>
</track>

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?

Yes, you are right. The best practice example on wiki page https://wiki2.railml.org/index.php?title=IS:signal does not match with the attribute description for @name and @code. The best practice example has to be modified as suggested by you, but also for the other two signals "Va" and "N2".

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Clearer modelling of the signal designation [message #2359 is a reply to message #2353] Fri, 28 February 2020 15:56 Go to previous messageGo to next message
Ferri Leberl is currently offline  Ferri Leberl
Messages: 24
Registered: September 2016
Junior Member
Dear All,
I just adapted the examples under https://wiki2.railml.org/index.php?title=IS:signal#Signal
I hope, it matches your point.
Yours, Ferri
Re: [railML2] Clearer modelling of the signal designation [message #2368 is a reply to message #2359] Wed, 04 March 2020 17:30 Go to previous message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 66
Registered: March 2008
Member
Dear all,

I deleted @code from the signal example, as the way it was used is not in accordance with Dev:identities.

I considered editing the codes into something random, but I concluded that it would not contribute anything to the example.


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Wed, 04 March 2020 17:36]

Report message to a moderator

Previous Topic: extension of <levelCrossing> in railML2.4nor
Next Topic: the use of @dir in railML.
Goto Forum:
  


Current Time: Fri Mar 29 11:45:53 CET 2024