Home » railML newsgroups » railml.timetable » new attributes in entry
new attributes in entry [message #640] Tue, 05 April 2005 13:32 Go to next message
markus.ullius is currently offline  markus.ullius
Messages: 8
Registered: November 2004
Junior Member
Working on the RailML-import for OpenTimeTable I miss the attributes
arrivalDelay and departureDelay. I propose to add them to the entry type
having numeric values (seconds).

Best Regards
Markus
new attributes in entry (add on) [message #641 is a reply to message #640] Wed, 06 April 2005 14:58 Go to previous message
markus.ullius is currently offline  markus.ullius
Messages: 8
Registered: November 2004
Junior Member
After some discussions and thinking about it there could be several
possibilities to have real data and
the corresponding delays:

1) Have the "real" and "planned" data in the RailML-file to be imported.
The problem with this variant is that you have to do a lot of housekeeping
while merging the entries
from "real" and "planned". Since as far as I can see no order is
guaranteed (e.g. first in the file you
have all planned data, then all real data or vice versa or you keep a
train's data together e.g. by having
all "planned" entries
of a train followed by all "real" entries (or vice versa)). But to handle
all these cases you'll build up
datastructures in memory to merge "planned" and "real". This requires
unnecessary memory and
makes importing process complex.

2) Change the element <timetableentries>
Doing so you could store data of a train in the trainblock, the
<timetableentries>-element could
contain the "planned" or "real" element. Example:

<train trainID="x"...>
<timetableentries dataStatus="planned">
//the corresponding entries...
</timetableentries>
<timetableentries dataDateTime="2005-01-01 dataStatus="real">
//the corresponding entries...
</timetableentries>
<timetableentries dataDateTime="2005-01-02 dataStatus="real">
//the corresponding entries...
</timetableentries>
</train>

This solution would at least keep a train's timetable-data together

3) Add elements in the <entry>-block

3a) arrivalDelay, departureDelay as numeric value or as duration

3b) scheduledArrival, scheduledDeparture as time, scheduledArrivalDay,
scheduledDepartureDay

This solution (3a or 3b) would give a compact format having scheduled and
planned timetabledata
avoiding to have double timetable-structures (for planned and real) and to
merge them in an
unconfortable way.

I would suggest 3a or 3b to keep things flexible and simple.

Best Regards
Markus Ullius
Previous Topic: Proposal Statistics (Summary)
Next Topic: Operator information
Goto Forum:
  


Current Time: Thu Mar 28 10:23:52 CET 2024