Home » railML newsgroups » railml.timetable » non-timetable blockParts with track occupancy and train coupling
Re: non-timetable blockParts with track occupancy and train coupling [message #1363 is a reply to message #1359] Wed, 15 June 2016 11:45 Go to previous message
Dirk Bräuer is currently offline  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.
 
Read Message
Read Message
Previous Topic: stopTimes - no reference to the times element
Next Topic: Minutes on railML meeting, 2nd of June, 2016
Goto Forum:
  


Current Time: Thu Nov 14 06:10:54 CET 2024