Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2478 is a reply to message #2472] |
Wed, 01 July 2020 10:34 |
Dirk Bräuer
Messages: 313 Registered: August 2008
|
Senior Member |
|
|
Dear Janne, Nadia, Milan and "along-readers",
concerning the question
> 1) trainPart or category?
I would say: <trainPartSequence>!
- With a @rank at <trainPart>, we would have the problem that a train consisting of <trainPart>s with different @ranks, which rank would the resulting train have? A mean value? Since Janne wrote she needs that attribute for a priority of trains in a simulation software, railML should provide a value per train.
- A @rank at <category> would fit since there is a @categoryRef at <trainPartSequence>. But I'm afraid in some countries the meaning of categories already lost their operational background, they could have a rather commercial background. I can easily imagine that many trains have the same <category> for formal reasons but different priorities. In Germany, currently all "private" trains (non-DB-trains) must have one of the limited categories starting with "D", so there is not much freedom to express priorities. At least the "government" categories have much more expression of priorities.
So, I think it would be good to separate categories and priorities, to be flexible giving two trains with the same <category> a (slightly) different priority. Since in every timetable there should be trains of the same category meeting each other, this would also allow to give the simulation software a "hint" of which one would be the more important by traffic means (rush hour direction or such).
So, I would recommend to keep a @rank at <category> and to add a @rank at <trainPartSequence> which optionally overwrites any @rank possibly inherited from <category>.
Concerning the question
> the actual type of @categoryPriority is a String.
I would agree that we can clarify this by constrains and best practices.
Concerning the question
> lower value means a higher priority
I would agree with that rule.
Best regards,
Dirk.
|
|
|