| problems with <train>s: uniqueness constraints, scope [message #913] |
Wed, 02 January 2013 11:27  |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Dear group,
we have some problems with the standard when mapping our model to railML
trains.
1. If I read the standard correctly, trainPartRefs within a trainPart
sequence model coupled trains. The wiki formulation
" Therefore all referenced elements trainPart of a trainPartSequence
should have the same starting point and end point"
hints to that but is not really strict enough. The formulation should be
changed to
"The <ocpsTT> of all <trainPart>s within a <trainPartSequence> should
contain the same sequence of <ocp>s with the same arrival and departure
times."
We could discuss what variation between the ocpsTT should be acceptable.
For instance, <stopDescription/onOff> could vary.
2. What variation of the trainPartSequences is allowed within one train?
The case
train x runs daily from A to B, and mon-fr a trainPart is added with
position 2, and a trainPartSequence from B to C
is apparently intended to be legal, while
train y runs daily from A to B, and mo, tue, wed it continues to C but
thu, fr, sat to D
is not.
If this is so, I suggest adding the following -hopefully clarifying-
text to the documentation:
"For any <train>, there is a sequence of ocpTT without locational or
temporal breaks, such that
- for any <trainPartSequence>, there is a section of that sequence such
that the ocpTTs of all referred trainParts of that trainPartSequence
correspond with that section
- the sections of subsequent trainPartSequences are subsequent to each other
- for any operatingPeriod, the trainPartSequences spanned by the
trainParts effective on that operatingPerid has no gaps."
3. The scope construct is intended to model variations in the path of a
train on different days. The wiki states the constraint
"The compound of the attributes trainNumber, additionalTrainNumber and
scope has to be unique for all <train> elements. If some of these
attributes is absent the others have to be unique. The code attribute is
used for some unique string identifying the train regardless of the
unique attribute triple.".
So a variation of a train path at an intermediate section should be
modelled with scope "secondaryInner" - but what if you have _two_
variations on different days? Also, the differentiation between
"secondaryStart / secondaryEnd / secondaryInner" is redundant with the
train path.
The constraint should be relaxed to allow variation of the train path on
disjoint operatingPeriods. If a designated "primary" path is needed, the
constraint should at least be relaxed to allow multiple trains with
scope secondaryXXX. In that case, I also propose to introduce a new
scope value "secondary" and to mark secondaryStart / secondaryEnd /
secondaryInner as deprecated.
--Andreas.
|
|
|
|
Members
Search
Help
Login
Home
