| Timetable data elements for railVIVID [message #1569] |
Fri, 12 May 2017 12:24  |
Philip Wobst
Messages: 47
Registered: November 2013
Location: Hanover, Germany
|
Member |
|
|
The railVIVID tool shall show an element count of all relevant elements in a railML file - TRAC ticket #230. I have created a list of elements that contain the main data for the TT subscheme based on existing example data files. Please note the following:
- parent elements (e.g. ocpsTT or connections) are not included
- sub elements that need to be provided together with a parent (e.g. the trainPartRef for the trainPartSequence) are not necessarily included
Please review the list below and provide feedback if you feel an element is missing.
Timetable masterdata
Element XPath expression
category //timetable/categories/category
operatingPeriod //timetable/operatingPeriods/operatingPeriod
operatingDayDeviance //timetable/operatingPeriods/operatingPeriod/operatingDay/operatingDayDeviance
specialService //timetable/operatingPeriods/operatingPeriod/specialService
holiday //timetable/timetablePeriods/timetablePeriod/holidays/holiday
Train data
Element XPath expression
trainPart //timetable/trainParts/trainPart
passengerUsage //timetable/trainParts/trainPart/formationTT/passengerUsage
reservationInfo //timetable/trainParts/trainPart/formationTT/reservationInfo
ocpTT //timetable/trainParts/trainPart/ocpsTT/ocpTT
connection //timetable/trainParts/trainPart/ocpsTT/ocpTT/connections/connection
sectionTT //timetable/trainParts/trainPart/ocpsTT/ocpTT/sectionTT
stopDescription //timetable/trainParts/trainPart/ocpsTT/ocpTT/stopDescription
times //timetable/trainParts/trainPart/ocpsTT/ocpTT/times
organizationalUnitBinding //timetable/trainParts/trainPart/organizationalUnitBinding
train //timetable/trains/train
trainPartSequence //timetable/trains/train/trainPartSequence
brakeUsage //timetable/trains/train/trainPartSequence/brakeUsage
speedProfileRef //timetable/trains/train/trainPartSequence/speedProfileRef
Train group data
Element XPath expression
trainGroup //timetable/trainGroups/trainGroup
trainRef //timetable/trainGroups/trainGroup/trainRef
Rostering
Element XPath expression
blockPart //timetable/rosterings/rostering/blockParts/blockPart
block //timetable/rosterings/rostering/blocks/block
blockPartSequence //timetable/rosterings/rostering/blocks/block/blockPartSequence
blockPartRef //timetable/rosterings/rostering/blocks/block/blockPartSequence/blockPartRef
circulation //timetable/rosterings/rostering/circulations/circulation
|
|
|
|
|
|
|
|
| Re: Timetable data elements for railVIVID [message #1576 is a reply to message #1569] |
Thu, 18 May 2017 12:59  |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Dear all,
I am sceptical that this approach leads to a practical solution.
From my understanding:
- The aim is to avoid a railML file with only "any-fields" (after a
minimum of <railML>).
- The statistic approach to reach this, which is discussed here, shall
lead to a kind of "cover ratio" of railML in a railML file.
I see the following problems:
- Nobody will know which minimum "cover ratio" will be acceptable.
- It depends on the use case which elements are obligatory and which
are optional. So, this approach conflicts with the concept of use cases.
I personally don't think that this should be solved in an automatic and
statistic way but if you want to follow this approach, I would recommend
to count only this elements which are "common to all use cases". Of
course nobody knows all use cases of the future, but analogously it
means: Relatively view, basic elements only. So most acceptable railML
files will have a high "cover ratio".
The current list, from my opinion, is too much unbalanced by containing
too many special and possibly still not all basic elements.
Best regards,
Dirk.
|
|
|
|
|
|
|
|
|
|
Members
Search
Help
Login
Home
