Home » railML newsgroups » railml.timetable » [railML2] Modelling of crossings/overtakings
[railML2] Modelling of crossings/overtakings [message #2401] Wed, 18 March 2020 13:22 Go to next message
Janne Möller is currently offline  Janne Möller
Messages: 14
Registered: March 2019
Location: Oslo
Junior Member
Dear railML community,

To model a crossing or overtaking procedure between trains, I would like to ask what the best practice for these are.

I would use the element <connection> to

  1. Refer to the train the crossing takes place with, and
  2. Specify the sequence of arrival of the trains with @connOperation (where the value "isWaitingFor" describes the train that arrives first and "isExpectedBy" the train that arrives last)
To specify what type of connection (crossing or overtaking) is taking place I would use the element <stopActivity>: @type="occupationCrossing" for a crossing, and @type="occupationBlock" for overtaking. Following the definition of these types, they describe "stop caused by ...", so these values (and <stopActivity> generally) are only to be used for a stopping train.

My question is how to specify the type of connection for the not-stopping train? Could stopActivity@type be used for passing trains too? As an example, the element <stopDescription> is also used if the attribute ocpTT@ocpType is set to "pass".

What are your thoughts on this?
Thanks in advance for your input!

Best regards,
Janne Möller
Re: [railML2] Modelling of crossings/overtakings [message #2402 is a reply to message #2401] Thu, 19 March 2020 10:44 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Janne,
dear community,

I dare to write that so far, it was not the intention of railML to explicitly model crossings or overtakings of trains. Therefore, I have some doubts on what you suggest:

1)
During the timetable developer meeting on 21st January 2020 in Dresden, it was discussed to use the <connection> element for more timetable linkings than passenger-taffic connections. There was no general agreement on this. So we must conclude that so far, passenger-taffic connections are the only timetable linkings which <connection> is intended to be used for - unfortunately. That's also why join/split/turnaround have been deprecated there since r2.1, and "meet", "IsWaitingFor" and "IsExpectedBy" have been clarified to be linked with _passengers_.

2)
There is probably no general accepted definition of what is a crossing and what is an overtaking. Consider that more than two trains can be involved - a train can be "isWaitingFor" and "isExpectedBy" at the same time, a crossings and an overtaking can occur at the same time. Some people would say that a crossing can also happen at the first or last station of a train. Other people would say that at the last station of each train, sooner or later always a next train begins, but despite this there is not always a crossing or overtaking at the first or last station of all trains.

This is of course no criterion for exclusion of crossings and overtakings from railML, but as you see, this leads very far. Surely the usage could only be a matter of use case.

3)
There is, as far as I can see, no hard exclusion to use <stopActivity> at ocpType='pass'. But it is surely not intended.

Please note that <stopActivity @type="occupationBlock"> does not necessarily encode an overtaking. The block can also be blocked because of a train in advance which never did overtake. On the contrary, this could be misleading because it should mean that the reason for the stop is that the block in advance is occupied when the train arrives (when the stop begins). This is normally not the case at the beginning of an overtaking.

---
However, my personal opinion:

I would welcome a possibility to encode crossings and overtakings in railML because we also have them in some German driver's timetables. But it would have to be a very flexible model (taking into account more than one train, operating days of trains etc.) and the actual definition of what is a crossing and an overtaking should be left to the use case.

In current railML 2.x, I would welcome to use <connection> for more timetable linkings, especially for (use-case dependant) crossings and overtakings. But at the same time, we must avoid that <connection> is used to create redundancies to <rostering> - and especially avoid that it is used instead of <rostering>.

I would prefer not to spread one background to two different places in railML. Means: keep <stopActivity> out of this, hold it all together at <connection>. Extend <connection> to encode more information on crossings and overtakings if necessary. Do not allow <stopActivity> at ocpType='pass'.

I think that your demand on encoding crossings and overtakings is general enough to be met by railML and should not be solved purely by extensions.

Best regards,
Dirk.
Re: [railML2] Modelling of crossings/overtakings [message #2403 is a reply to message #2401] Thu, 19 March 2020 12:17 Go to previous message
Vasco Paul Kolmorgen
Messages: 55
Registered: November 2004
Member
Dear Janne,

thank you for the interesting question regarding the modelling of
crossings and overtakings. First of all I would like to learn for what
kind of use case this need for a railway data exchange is given in
Norway. Could you describe a little bit more detailed?

From my opinion your proposal could lead for some new semantic
constraints, e.g. what happens, if you define a
<stopActivity>@type="occupationCrossing" for a crossing but there is no
crossing train the this file which fits to the train to be crossed.
Such semantic constraints must be described very carefully and adapted
to the (in railML 2 mostly unknown) use cases in order to avoid further
queries.

The central question would therefore be from the perspective of the
long-term usability of the railML schemes: In which application case
shall an crossing and overtaking also be transferred and read in within
the framework of a data exchange between two software systems and could
this not also be clearly determined by evaluating the data that already
exists?

Best regards,
--
Vasco Paul Kolmorgen - Governance Coordinator
railML.org (Registry of Associations: VR 5750)
Phone railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Am 18.03.2020 um 13:22 schrieb Janne Möller:
> Dear railML community,
>
> To model a crossing or overtaking procedure between trains,
> I would like to ask what the best practice for these are.
> I would use the element <connection> to Refer to the train the crossing
> takes place with, and
> Specify the sequence of arrival of the trains with
> @connOperation (where the value "isWaitingFor" describes the
> train that arrives first and "isExpectedBy" the train that
> arrives last)
>
> To specify what type of connection (crossing or overtaking)
> is taking place I would use the element <stopActivity>:
> @type="occupationCrossing" for a crossing, and
> @type="occupationBlock" for overtaking. Following the
> definition of these types, they describe "stop caused by
> ...", so these values (and <stopActivity> generally) are
> only to be used for a stopping train.
>
> My question is how to specify the type of connection for the
> not-stopping train? Could stopActivity@type be used for
> passing trains too? As an example, the element
> <stopDescription> is also used if the attribute
> ocpTT@ocpType is set to "pass".
>
> What are your thoughts on this?
> Thanks in advance for your input!
>
> Best regards,
> Janne Möller
Previous Topic: Extension of Enum @trainUsage of <category>
Next Topic: Current status of railML 3.2 TT modelling (sneak peek)
Goto Forum:
  


Current Time: Tue Jul 23 13:27:13 CEST 2024