TAF/TAP TSI

We agree with the CR, but propose slight modification of text for annotation:

The OffsetToReference (OTR) is the shift of the days in Planned Calendar of the related object (route, path request or path) to the days in Reference Calendar. The shift is mentioned in days. OTR value is set to zero when there is no shift/offset between Planned Calendar and Reference Calendar, OTR value is positive if Planned Calendar later than Reference Calendar and negative if Planned Calendar earlier than Reference Calendar.

Please take it into account:

- PlannedCalendar is used in PassengerTrainCompositionMessage as well.

- New element OTR has to be include also in element RequestedCalendar.

TEG O puts this CR On-Hold since there were a few objections. The requester should answer the open questions from the list above.

TEG O puts this CR On-Hold since there were a few objections. The requester should answer the open questions from the list above first.

TEG O approves this CR.

Thanks for the hint. I did it.

The ReceiptConfirmationMessage will be examined as a possible solution. A proposal will be prepared.

TEG O Approves this CR. The Annotation part from the xsd is missing in order for the CR to be discussed on the SMO.

Approved by TEG O

The purpose is to include the itinerary as an optional element. What is the problem of including another optional element? There are several optional elements in every message...

Adif supports this CR.

We support this CR.

We support this CR. Even if RUs get the data from TIS, TRI should include this information.

Just to clarify, if the GeoLocalisationOnNetwork element is added in TrainLocationReport level, this information could be used in TrainRunningForecastMessage (which, from our point of view, is good), right?

SZCZ doesn't support this CR - already existing messages, in this case it is ReceiptConfirmationMessage (RCM), shall be utilized. If RCM is not coping with the needs, then the message shall be subject of CR (but we think that the message is not dedicted only for Path Request process).

I could understand your point, but believe me, this additional message doesn't come from IT, but from the business side. At least in Spain, according to our current regulation, the compositions have to be accepted/denied by the IM (Adif, in this case).

I think we don't need additional messages especially for the TrainPreperationPhase. Please don't overload the involved parties of the railway business with needless messages. Our main purpose and focus and our business is to drive trains and to satisfy our customers and not to satisfy the IT-guys... With the TCM the RU give the information about the TrainComposition to the IM (or to the next RU if the HERMES-message is not used - for whatever reason). If the allowed parameters and regulations are respected in the train composition is up to the RU. So there is no need to validate and to confirm the TCM bym the IM. Otherwise we have an additional time-consuming process during the train-preperation process. And as you know, especially in the intermodal business the time between incoming of the orderdata and the departuretime of the train is even short enough. So if we implement another message in this small time-frage, it won't improve the competetiveness of railway business and it is even not necessary.  

The thing is that if the RU received that the TrainReady was successfully processed, the RU could discard a communication or system failure, and, as you have perfectly explained, the cause of the signal in red would be different.