Home » railML newsgroups » railml.timetable » [railML2] Extension proposal: pattern trains, distributions and slots
[railML2] Extension proposal: pattern trains, distributions and slots [message #2555] Tue, 13 October 2020 14:32 Go to next message
Janne Möller is currently offline  Janne Möller
Messages: 12
Registered: March 2019
Location: Oslo
Junior Member
Dear railML-community,

For the use case of long-term timetabling we added extensions to railML2.4 in the Norwegian railway sector (railML2.4nor) concerning pattern trains, that we would like to present to you.

A pattern train is a template for other trains. The container element <nor:patternTrains> is located directly under <timetable>. A <nor:patternTrain> is not itself a train that is supposed to run. It uses the same attributes and sub-elements as the element <train> and additionally the following newly introduced attributes: @interval (intervals in seconds between trains), @trainsPerHour (number of trains per normal traffic hour), @trainsPerDay (number of trains per normal traffic day), @trainsPerWeek and @distributionRef (reference to a more detailed distribution, as described below).

When the interval is fixed, it can be given as a single value, e.g. "600" for a pattern that will run every 10 minutes. If the interval varies in cycles, the cycle can be given as space-separated values, e.g. "600 900 300" for a pattern that will run with 10 minutes between the first and second departure, 15 minutes between the second and third and 5 minutes between the third and fourth, before the interval pattern repeats, in this case every 30 minutes. It is not required that the (sum of the) interval(s) evenly divides a whole hour, and a pattern that does not repeat at the whole hour carries over into the next. As an example, an interval of "2400", i.e. 40 minutes, would give a pattern that produces the same minutes of the hour every two hours.

A fixed number of departures per hour, day or week can be given using the respective attributes. As the number of departures per hour in a pattern can vary during a day, and similarly the number of departures per day over a week, we also needed a way to describe a more generalised distribution. The container element <nor:distributions> that includes any number of <nor:distribution> elements is placed directly under <timetable> in the schema. A <patternTrain> element can refer to a distribution using the attribute @distributionRef. In this way, one distribution can also be used for multiple pattern trains. With <nor:distribution>, the distribution of trains over the course of a time period such as one day can be described in a detailed and flexible way. For this, one or more <nor:slot> sub-elements are used. Each slot describes the number of trains (@numberOfTrains) in a certain time window (@duration) from a given starting time (@startTime).

Additionally, a <trainGroup> can have an attribute @nor:patternTrainRef, that refers to the <nor:patternTrain> functioning as a template for trains in that <trainGroup>.

Any feedback is highly appreciated.

Best regards,
Janne Möller
Jernbanedirektoratet
Re: [railML2] Extension proposal: pattern trains, distributions and slots [message #2558 is a reply to message #2555] Thu, 15 October 2020 11:47 Go to previous message
Milan Wölke is currently offline  Milan Wölke
Messages: 49
Registered: April 2007
Member
Hi Janne,

first of all thanks for your proposal.
I understand that you are interested in adding this to the standard in 2.5. We have discussed this in a first round in the timetable developer group and in general there was positive feedback regarding the idea of adding the possibility to model this kind of patterned approach. However there was also concern regarding the complexity of the chosen approach.

For me one major question is this, if the patternTrain has all the attributes and elements of a train (patternTrain is derived from train in your approach AFAIK), is the meaning of all those attributes and elements clear. For example, what is the meaning of a trainNumber that could be specified for a patternTrain. Same goes for the tafTapTsiID that can be specified for a train and thus as well for a patternTrain?

I read in another post regarding the nor extensions that you introduced rules regarding the train numbers for trainGroups (trainNumbersFrom, trainNumbersTo - https://www.railml.org/forum/index.php?t=msg&th=764& start=0&), which can refer to patternTrains (as they already can refer to trains and patternTrain is intended to be a subclass of train). Wouldnt it make more sense to allow specifying a trainNumber pattern along with the patternTrain rather than providing them only with trainGroup?

Another feedback from the community was, that as the newly introduced complexity of this is rather high, could you provide some examples for this, especially some that refer to trainParts with different operatingPeriods, along with some explaination on how to interprete those?

Another question I came across is the meaning of the cancelled flag for a pattern train? Would cancelled=true mean that all trains described thus are cancelled? How would one model a scenario, where only one/some of the described trains need to be cancelled?

Would be great if you could help my clarifying those so we can better discuss the pros and cons of the modelling. Thanks in advance.

Best regards, Milan




Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML2] Extension proposal: train numbers in <trainGroup> and a "group of groups"
Next Topic: [railML3] Places/Service in rollingstock
Goto Forum:
  


Current Time: Thu Oct 29 03:26:25 CET 2020