Today's Messages (off)  | Unanswered Messages (on)

Forum: railml.infrastructure
 Topic: [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, 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
( 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
 Topic: Station borders
Station borders [message #2318] Fri, 24 January 2020 17:31
christian.rahmig is currently offline  christian.rahmig
Messages: 249
Registered: January 2016
Senior Member
Dear all,

in the SCTP use case working group we recently discussed about borders of stations and their representation in railML 3.x.

There are several candidates for implementation:
* a dedicated <border> element
* evaluate (linear or area) location of <operationalPoint>
* topology-based aggregation of <netElement>

But before we think about the specific implementation, let me first ask you, dear community, whether you need to distinguish between "in-station" and "outside-of-station" and - if needed - which attributes do you expect the border to have?

As usual, any feedback is highly appreciated...

Best regards

Christian Rahmig - Infrastructure scheme coordinator (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany

Current Time: Mon Jan 27 22:36:55 CET 2020