Home » railML newsgroups » railml.timetable » Attribute processStatus to be declared deprecated for <train>, <trainPart> and <trainGroup>
| Re: Attribute processStatus to be declared deprecated for <train>, <trainPart> and <trainGroup> [message #2335 is a reply to message #2331] |
Wed, 19 February 2020 13:57   |
Torben Brand
Messages: 158
Registered: March 2016
|
Senior Member |
|
|
Dear TT community,
We value the quick reply and the suggestions by iRfP. However, we suggest not to make a new attribute, but to reuse @proccesStatus, as a pragmatic approach, as railML2 is in the end of its life cycle (But as they say in German: "the doomed live the longest ;-)"). This will NOT alter the values or the use of @pathStatus. We suggest reconstructing a cleaner model in railML3. Especially one that is aligned with the new TTR process of Rail Network Europe (http://rne.eu/sales-timetabling/ttr/).
Jernbanedirektoratet has discussed the TT process stages including the slot allocation process with the Norwegian IM Bane NOR. We have reached a common suggestion for a flexible and pragmatic implementation suggestion in railML2.
The general process phase/stage of the model is global for the railML file/transmission. This stage should be submitted, if desired, in the <metadata> element of railML. As these stages differ per country/IM today and differ in TTR we suggest NOT to standardise this information. An example for the global file @proccesStatus/@pathStatus metadata information could be:
<dc:source>proccesPhase: tactical (long term timetable negotiations) SubPhase: (X-5) Slot proposal published (offer from IM back to operators after their initial slot order) </dc:source>.
We have generalised the phases/stages of a timetable from idea to actual operated train (also see illustration) to the values: strategic, tactical, operational, historic. These could be used in the metadata together with more detailed description (see example above).
The individual elements could use the set value list of @pathStatus. For completeness we suggest extending the value list in either end of the timeline with "conceptual" and "actual".
We suggest the following value definitions:
We refer to "element" as being either trainPart, trainPartSequence, train or trainGroup
"conceptual" for slot construction or commissioning of the element, which is planned for the medium or long term. However, there are still no concrete (planning) activities for the construction of the element beyond the preliminary planning. Used in UC/phase TT:LongTermStrategicTimetabling and as a draft example from the commissionaire in UC/phase TT:ATimetableForACompetition.
"planned": The construction or commissioning of the element is planned concretely and at short notice or concrete planning activities for the construction take place, e.g. design, approval or implementation planning, cost calculation, award of contracts (bid). It is not normally possible to use the element (run the train) as it has not been ordered and approved. Used in the proposal in UC/phase TT:ATimetableForACompetition and in UC/phase TT:SlotOrdering.
"ordered" The element is ordered for a slot allocation process from the bid party (railway undertaking/operator) to the capacity allocation authority (infrastructure manager).
"detailsRefused" The element has been reviewed (by the capacity allocation authority) and details have been modified/changed/adjusted pending approval by the initial ordering/bid party.
"confirmed" The element has been reviewed and approved (by the capacity allocation authority) as ordered by the initial ordering/bid party.
"cancelled" The element has been cancelled, but service will be maintained through a train replacement service (usually a buss). The service will be announced. Used in combination with @cancellation="true"
"notAvailable" The element has been retraced and there will be no other (train) service. This possible due to an error in the planning. The service will not be announced. Used in combination with @cancellation="true"
"actual" These are actual driven/operated trains and the time values with time@scope="actual" CAN have been set.
We suggest making the value list more flexible placeable. Comparable to IS:state which is placed on several elements including the <infrastructure> root element. For this we suggest to use, in addition to @pathStatus,@proccesStatus as this is already available under <train>, <trainPart> and <trainGroup>. In railML2.5 it should be considered placing the attribute also on <timetable> for a set global value that inherits/apply to all elements unless defined further down the hierarchy and thus breaking/overwriting the inherited value.
This makes it also possible to mix different process state values for different trains in the same file. For instance, you can indicate "conceptual" trains to indicate a desired template/pattern (but which shall never run as actual trains) on a <trainGroup> together with the "confirmed" trains (that run later in the process after the path allocation has been closed unless operative cancelled) on <train>.
With the correct use of other:* and extended to the Norwegian use case we will use the following values:
@pathStatus="nor:conceptual" and "nor:actual" in addition to the existing values.
@processStatus="nor:conceptual","planned","nor:ordered", "nor:confirmed","nor:detailsRefused","nor:cancelled","nor:notAvailable " and "actual".
We suggest NOT to use in @processStatus the values: "calculated", "toBeChecked", "changed" and "imported". This as the general data state can be set in <metadata> (calculated/imported) and annotations can be set in combination with @proccessStatus/pathStatus (toBeChecked/changed).
Example:
An operator orders 6 train slots at two IM's. All train@processStatus="ordered". Additionally, the operator delivers a pattern train with trainGroup@proccesStatus="conceptual" to indicate the desired pattern for a service.
The review of one of the IM's result in: two of the trains are partially outside its jurisdiction. The but the part inside its area is ok for one train (trainPartSequence@pathStatus="confirmed"), but can only be accommodated for one of two trainParts for the other train (trainPart@proccesStatus="notAvailable" and "confirmed" for the other) For the remaining 4 trains completely inside it's area 2 trains are ok as ordered (train@proccesStatus="confirmed" or trainPartSequence@pathStatus="confirmed" for all trainPartSequence of the train). For one train some of the departure times of a trainPart must be adjusted (trainPart@proccesStatus="detailsRefused") and the last train cannot be accommodated at all (train@proccesStatus="notAvailable").
Please note that this is just a suggestion and should not interfere with existing use of railML.
PS. I was not able to upload a picture or an PDF attachment to this reply. And formating is a cumbersome afair in the forum. So I have placed a pdf with formating and illustrations here:
http://cloud.railml.org/index.php/s/JeZ5qNffx8Aetqz (public link that will expire 4.3.2020 as set by the cloud system)
|
|
|
|
Current Time: Sun May 05 00:11:58 CEST 2024
|
Members
Search
Help
Login
Home
