| Re: [railML2] Consistent definitions of formationTT@load @weight and @timetableLoad [message #3028 is a reply to message #2664] |
Tue, 12 July 2022 15:29   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Torben and all,
since Milan asked to get a reply on this post: There are no objections from our side. We agree that a @load or @timetableLoad at a <formation> with no wagons is a valid way to encode a load with "virtual" wagons.
Some hints on wording:
> If there are defined wagons in the formation (either real wagons with real weight and length values or a dummy wagon of 1m length and 1t tareweight) the formationTT values overwrite these values.
Acceptable, but very much on the borderline... I would object against any intentionally coding of wrong train lengths. So a wagon of a placeholder-length 1 m or mass 1 t would _have_ _to_ _be_ overwritten by the formation or train. It would not be acceptable that any of these placeholders come into effekt at the final train. (I would prefer to define wagons without length and mass instead of placeholder values.)
> @weight: the actual weight of the formation while in use, including any possible engine(s)
> @load: (introduced with version 2.1) the actual driven load of the formation, excluding any possible engine(s)
> @lenght: the planned length of the complete formation according to the timetable.
> @speed: the planned maximum speed of the formation according to the timetable.
> @timetableLoad: (introduced with version 2.1) the planned load according to the timetable, excluding any possible engine(s)
I recommend avoiding the word "actual" since we are still in <timetable>: Everything here is planned, in advance. It is usually not the task of <timetable> to encode data in retrospect, so "actual" data of the past. This would open up the problem that a train can only have a certain (actual) load per day, so the load would differ from day to day. In case you do not agree to this and you want to allow to encode data of the past here, there should be at least the constraint that in such a use case only _one_ operating day (of the past) is allowed.
Best regards,
Dirk.
[Updated on: Tue, 12 July 2022 15:51] Report message to a moderator |
|
|
|
Members
Search
Help
Login
Home
