|Blockparts: emptyRuns, depotRuns [message #949]
||Fri, 25 October 2013 17:28
Registered: March 2012
the wiki page on <blockPart>s is inconsistent.
- It says that for missions fullRun, emptyRun, <trainpartref> must not
be used, but a "note" on the bottom of the page says the opposite for
- The English text says that depotRun is "not a run", in the German
text this mission type is missing.
Is a depotRun a trip to a depot? Then I would think that it _is_ a run,
and start and end will be different.
Also, shouldn't, instead of start and end ocps, rather <ocptts> be used
for those missions that are runs? Referencing a trainPart I think is not
optimal, because so far they are always used in connection with a train,
and we don't have a train for those runs.
Finally, it would be nice if we could clarify the semantics of shunting,
emptyRun, fullRun and depotRun.
|Re: Blockparts: emptyRuns, depotRuns [message #954 is a reply to message #949]
||Tue, 19 November 2013 16:33
Registered: August 2008
Dear Andreas and "along-readers",|
> the wiki page on <blockPart>s is inconsistent.
> - It says that for missions fullRun, emptyRun, <trainpartref> must not
> be used, but a "note" on the bottom of the page says the opposite for
I think it is not inconsistent but capable of being misunderstood: The
"note" on the bottom of the page does not say the opposition for _the
enumeration value_ “emptyRun” but for one of two possibilities to express
an empty run in general.
- There are two possibilities to express empty runs (in general) as the
note of Joachim says.
- The enumeration value “emptyRun” is to be used only if the attribute
/trainpartref/ is not existing. This is the second possibility (“loosely
- The other way is an empty run “planned in all details in the timetable”.
This must have the /trainPartRef/ attribute and therefore the /mission/ =
> Is a depotRun a trip to a depot? Then I would think that it _is_ a run,
> and start and end will be different.
I think we can clarify this in the meaning of the footnote written by
Joachim: Everything (each <blockPart>) with the attribute /trainPartRef/
shall have the /mission/ = “timetable”. (This should be an easy signalling
to the parser to look for the /trainPartRef/ attribute.) So, the /mission/
= “depotRun” is away for the runs with timetable (“planned in all
details”). It is still usable for “loosely planned” runs. You can use it
for a trip to a depot (if “loosely planned”) as well as for a trip inside
the depot (something like shunting). There is so far no further definition
--> I suggest to extend the formulation “A duty which is not a run” by
“…or which is a run ‘loosely planned’”. If nobody contradicts I will do
this change in some weeks.
> Also, shouldn't, instead of start and end ocps, rather <ocptts> be used
> for those missions that are runs? Referencing a trainPart I think is not
> optimal, because so far they are always used in connection with a train,
> and we don't have a train for those runs.
There should not be references to trainParts in <blockPart>s which have
There cannot be references to <ocpTT>s because <ocpTT>s are sub-structures
of <trainPart>, and since we have no <trainPart>s for such <blockPart>s,
we also have no <ocpTT>.
The <ocpTT>s of the "surrounding" trains cannot be references because
depending on the operation day, these could be different "surrounding"
trains around a duty such as "refuel". Additionally, two or more such
duties without <trainPart>s could follow: A "refuel" can be followed by
"shunting" can be followed by "pre-heating".
Please look at the examples for more information.
> Finally, it would be nice if we could clarify the semantics of shunting,
> emptyRun, fullRun and depotRun.
I guess the footnote of Joachim aimed to do so. We could write more on
this but before I would like to “hear” (read) the opinion of Joachim. My
suggestion is to add two examples (directly on the Wiki page) on a
“loosely planned” and a “timetable planned” empty run, full run, and depot
run and a (of course non-timetable planned) shunting.