Feature requests for timetable schema [message #672] |
Tue, 04 March 2008 23:24 |
susi
Messages: 4 Registered: January 2006
|
Junior Member |
|
|
Hello,
in current projects there occured amongst others the following feature
requests for timetable sub schema:
* a "trainPart" structure parallel to "trains" with quite all
attributes from "train", only the "formation" with its data should
be fix for "trainPart"; references from "train" to "trainPart"s and
back should be optional
* operating-period-depended formation data for "train", e.g. other
formation at weekend, but same train
* an in-between element between "train" and "entry" for section
information along some track (e. g. between major stations), some of
current "section" data could be transferred into
* attributes for reservation data: booking number of actual wagons
* actual brake usage data about "formation" used in timetable,
independent from brake possibilities in rollingstock
* actual passenger data about seat capacity in 1st and 2nd class and
catering in timetable, independent from possibilities in
rollingstock
* ...
On 13th meeting in Bern, I will present some ideas for integrating it
in current railML 1.1
Feel free to comment, discuss or expand.
See you at meeting.
Best regards,
Susanne Wunsch.
|
|
|
Re: Feature requests for timetable schema [message #673 is a reply to message #672] |
Wed, 12 March 2008 17:33 |
Joachim Rubröder railML
Messages: 0 Registered: November 2019
|
|
|
|
Hi,
here some feedback on your requests:
* a "trainPart" structure parallel to "trains" with quite all attributes
from "train"
-> I dislike the duplication of the structures, but I agree that your
"trainParts" cover a new aspect connected with rosterings.
What about declaring the current "train" as beeing the same as your
"trainPart"? We could also declare the formation as fixed within a
"train". Beside this, we could establish a new structure called
"trainGroup" (because there are some relations to the current
trainGroupID) with references to the trains in the way you suggested.
Please make a more detailed proposal (here in the forum), so that we can
discuss about it and may get some feedback from other users.
* operating-period-depended formation data for "train"
-> this should be easy, with an optional operatingPeriodRefId at the
formationTT-Element
* an in-between element between "train" and "entry" for section
information along some track
-> the current section was meant to describe data for the part between two
adjacent entries. The drawback is, that is has a sectionID but nothing to
reference within the infrastructure schema. Your new routeSection would be
quite the same on a higher level but also without references to the
infrastructure. What about using the current or modified "section"-element
in your sense, located only at selected entries? I would prefer this way,
until we have a corresponding (station-based) structure inside the
infrastructure schema.
* attributes for reservation data: booking number of actual wagons
-> interesting new aspect, please make a detailed suggestion (here in the
forum) how this could be done
* actual brake usage data about "formation" used in timetable,
-> I agree to build a "formationTT" or "formationUsage" as sub element of
an entry. This should also contain the existing "dynamic"-element with the
brake usage data.
* actual passenger data about seat capacity in 1st and 2nd class and
-> interesting new aspect, please make a detailed suggestion (here in the
forum) how this could be done
Best regards,
Joachim Rubröder
|
|
|