| non-timetable blockParts with track occupancy and train coupling [message #1359] |
Mon, 06 June 2016 16:05  |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
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.
|
|
|
|
| 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.
|
|
|
|
Members
Search
Help
Login
Home
