Re: non-timetable blockParts with track occupancy and train coupling [message #1363 is a reply to message #1359] |
Wed, 15 June 2016 11:45 |
Dirk Bräuer
Messages: 313 Registered: August 2008
|
Senior Member |
|
|
Dear Andreas,
"mission=timetable" does not necessarily mean that it has to be a train
in the German operational sense. There is no 'hard' accepted definition
to distinguish between 'train operation' and 'shunting movement'.
Regarding railML, any scheduled operation will fit here - so, a shunting
operation will also do:
- use "mission=timetable",
- use the <trainPart> category to identify shunting movements,
- use elements and attributes of such <trainPart>s as needed.
Please do not use <other:myShuntingMissionType> since this would weak
the standard in a case which is rather "normal" or "often".
Does this answer your question or did I possibly not understand the
question rightly?
Best regards,
Dirk.
---
Am 06.06.2016 um 16:05 schrieb Andreas Tanner:
> Dear community,
> the standard currently does not allow <blockPart>s with referenced
> <trainPart>s with any <mission> other than timetable. This means that
> these <blockPart>s cannot have track information (as there is no
> <ocpTT>, only <startOcp> and <endOcp>), nor can the fact that they come
> coupled with other <blockPart>s be exported in railML.
>
> Is there any best practice to circumvent that problem? We consider using
> an <other:myShuntingMissionType> and referencing <trainPart>s, and using
> the <trainPart> category to identify non-trains (that is, shunting trips
> etc.)
>
> Best regards, Andreas.
|
|
|