Home » railML newsgroups » railml.timetable » [railML2] Extension proposal: train numbers in <trainGroup> and a "group of groups"
Re: [railML2] Extension proposal: train numbers in <trainGroup> and a "group of groups" [message #2662 is a reply to message #2613] Thu, 18 February 2021 17:43 Go to previous messageGo to previous message
Torben Brand is currently offline  Torben Brand
Messages: 158
Registered: March 2016
Senior Member
Dear TT comunity,

After internal discussions we retract the suggestion for the new attributes @trainNumbersFrom and @trainNumbersTo in <trainGroup>.

We would still like to have the possibility to group traingroups hierarchical with the suggested new attribute @parentRef.

Christians Rössigers interpretation is as intended.

To elaborate on Milans question for more background we have different UC's:

Collections: These are groups of trains (<trainGroup>) that are used in the conceptual planning process where there are still different variations of the same train services. These variations are usually smaller changes to a train services slot, so that the different variations of the trains are "overlapping" each other and not meant to operate at the same time. But one is to be chosen in a later planning stage. There is a need to transfer all variations in the same railML file. As there can be a high amount of variations, these are structured in hierarchical groups of groups. Like for instance: different high-level conceptual scenarios containing different alternatives containing different smaller variants of the individual trains. With this information the receiving system can allow to filter on the appropriate trains in the transferred train group hierarchy.
The above-mentioned example is typical for pattern trains as they are used conceptual, they usually need to be grouped in collections.

A further extension on this UC would be, as discussed in the TT telco, to map variations (like rush hour frequency increase) within a <patternTrain>, where the <trainGroup> is the pattern trains grouping into a pattern train with variations and the referenced <patternTrain>s the pattern train variations. The @parentRef is then needed if you would like to group the pattern train (group) with variations in a collection group or other group.

We think it is important to be able to relay the relations between the groups (and secondarily also not to bloating the file size unnecessary) with the use of @parentRef and keeping the hierarchy information contained, instead of flattening the groups by repeating the trains for each individual group.


With kind regards
Torben Brand on behalf of Jernbanedirektoratet

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: [railML2] Ranking of tracks in track info
Next Topic: [railML2] Extension proposal: pattern trains, distributions and slots
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri May 17 02:20:58 CEST 2024