Home » railML newsgroups » railml.timetable » @categoryPriority of <category> to be declared deprecated in version 2.5
@categoryPriority of <category> to be declared deprecated in version 2.5 [message #2277] Tue, 26 November 2019 18:03 Go to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior Member
Hi,

bei einem Review der Dokumentation für das Element <category> im Wiki im Rahmen der TT-Developer Telcos sind wir auf das Attribut @categoryPriority gestoßen. Dieses Attribut ist als String definiert und erlaubt beliebigen Freitext, der dann durch das lesende Programm interpretiert werden muss. Da der Standard keinerlei Vorgaben bzgl. des Inhalts macht, muss es eine Abstimmung zwischen Produzent und Konsument geben, was ja eigentlich durch den Standard vermieden werden soll. In der Developer Group ist keine aktive Verwendung des Attributs bekannt. Entsprechend hat sich die Gruppe dafür ausgesprochen dieses Attribut mit railML 2.5 für deprecated zu erklären. Sollte es Verwendungen des Attributs in der Community geben, die einem solchen Schritt entgegenstehen würden, bitte ich darum diese hier vorzustellen. Vielen Dank schon mal im Voraus.

-------------------------------------------------

during a review of the documentation for the element <category> in the Wiki within the TT-Developer Telco we came across the attribute @categoryPriority. This attribute is defined as string and allows any free text, which has to be interpreted by the reading program. Since the standard does not make any specifications concerning the content, there must be a coordination between producer and consumer, which should actually be avoided by the standard. No active use of the attribute is known in the Developer Group. Accordingly, the group has decided to declare this attribute deprecated with railML 2.5. If there are uses of the attribute in the community that would stand in the way of such a step, please introduce them here. Many thanks in advance.

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: @categoryPriority of <category> to be declared deprecated in version 2.5 [message #2284 is a reply to message #2277] Wed, 04 December 2019 16:32 Go to previous messageGo to next message
Janne Möller is currently offline  Janne Möller
Messages: 14
Registered: March 2019
Location: Oslo
Junior Member
Dear Milan and railML-community,

since I am new in the railML timetable community, I would first like to introduce myself: My name is Janne Möller and I work at the Norwegian Railway Directorate in Oslo. We are currently working on a unified usage of the timetable scheme (and possibly needed extensions) within the Norwegian railway sector.

For simulation purposes we want to use the abovementioned @categoryPriority, so we would very much like to keep this attribut. Though we will be using the free string to set in values that correspond integer values, with a higher value meaning a lower priority.

Additionally we have the requirement to specify the priority of a trainPart, in case it differs from the referenced category priority. We are planning to add an extension to a Norwegian version of railML2.4 (railML2.4nor), and would like to propose a category-attribute for train parts in future railML-versions. In railML2.4nor we will use this attribute with type integer.

Best regards,
Janne Möller
Re: @categoryPriority of <category> to be declared deprecated in version 2.5 [message #2289 is a reply to message #2284] Mon, 09 December 2019 13:56 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior Member
Hi Janne,
thanks for your feedback and welcome to the community. Can you please outline the usecase for your intended use of these priorities? You mentioned simulation, could you provide some detail so we can better understand what you need to do. Maybe there is a better way of modelling this, after all the @categoryPriority is just a string...

Thanks in advance.

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2291 is a reply to message #2284] Wed, 11 December 2019 21:21 Go to previous messageGo to next message
Vasco Paul Kolmorgen
Messages: 55
Registered: November 2004
Member
Dear Janne,

thank you for the feedback. railML.org welcomes the work on the uniform
use of the railML-TT schema in Norway.

Can you describe an usement/example for the use of
<railml><timetable><categories><category>@categoryPriority in Norway for
the wiki page and maybe also specify the using programme and use case?
Maybe we could contact this railML partner and ask for in-depth
documentation to publish in the wiki after discussion in the TT
developers group. This would help the community to use the element in a
proper manner.

Regarding the extension of the attributes of the train part, a modelling
suggestion here in the forum and an introduction in one of the upcoming
TT developer phone calls would certainly make sense. Ideally, the
extension in railML2.4nor would be identical to the new modelling in
railML 2.5, which would reduce the later conversion effort for all
participants.

A question: How should the priority be processed, if it is indicated at
the same time at the train part and at the category? Can you make the
corresponding railML2.4nor documentation (also about higher priority
ascending/descending) available to the railML community and the Wiki?

Thank you and kind regards,

Vasco
--
Vasco Paul Kolmorgen - Governance Coordinator
railML.org (Registry of Associations: VR 5750)
Phone railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Am 04.12.2019 um 16:32 schrieb Janne Möller:
> For simulation purposes we want to use the abovementioned
> @categoryPriority, so we would very much like to keep this
> attribut. Though we will be using the free string to set in
> values that correspond integer values, with a higher value
> meaning a lower priority.
>
> Additionally we have the requirement to specify the priority
> of a trainPart, in case it differs from the referenced
> category priority. We are planning to add an extension to a
> Norwegian version of railML2.4 (railML2.4nor), and would
> like to propose a category-attribute for train parts in
> future railML-versions. In railML2.4nor we will use this
> attribute with type integer.
>
> Best regards,
> Janne Möller
Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2324 is a reply to message #2291] Mon, 10 February 2020 14:00 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior Member
Any news here?

Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2332 is a reply to message #2324] Wed, 19 February 2020 08:39 Go to previous messageGo to next message
Janne Möller is currently offline  Janne Möller
Messages: 14
Registered: March 2019
Location: Oslo
Junior Member
Dear Milan and Vasco,

Thank you for your feedback and apologies for the long answering time on my part.

We would like to specify a rank/priority for trains in timetable simulations using railML, as this characteristic is used for conflict solution during the simulation process. Also are we planning to use the information about the rank of a train or a category in the timetabling process to determine for example crossing patterns.

To enable the possibility to not only define a rank/priority for all train parts belonging to one category, but also for deviation of one or several train parts, we would highly welcome the introduction of a new attribute with type integer that can contain this information within the element <trainPart> in railML2.5. For the development of railML2.4 with Norwegian extensions, we are planning to use a new attribute called @nor:rank, also within <trainPart> with type integer. We suggest that the smaller the number the higher the priority of the train part is, with 1 being the highest priority.

Concerning the attribute @categoryPriority we see two possibilities:

  1. We could use the attribute @categoryPriority with the same possible values like in @nor:rank because they have to be comparable. But yes, the actual type of @categoryPriority is a String.
  2. Alternatively, in the Norwegian extensions we could introduce the attribute @nor:rank with type integer also under <category>, thus making it clear that the two @nor:rank attributes are connected and ensuring the same datatype. This seems to be a cleaner solution that we would prefer. Could it be a possibility to deprecate @categoryPriority as planned, but introduce an attribute like @rank in 2.5 instead?
As for having a rank/priority in both <category> and <trainPart> we suggest a hierarchy: the value of <category> applies to all <trainPart> elements of this category unless something different is specified in <trainPart>.

What are your thoughts on this?

Best regards,
Janne Möller
Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2348 is a reply to message #2332] Wed, 26 February 2020 11:58 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior Member
Hi Janne,

thanks for the explanation. With type integer this makes a lot more sense. From my point of view the best solution here would be to declare @categoryPriority deprecated as it simply isnt clear how to use it. In consequence data exchange regarding this attribute is not really possible without additional coordination between the two data exchange partners. In order to distinguish two versions of the same train a rank attribute sounds reasonable. However there are two questions I see here:
1) trainPart or category? I guess this depends on how the simulation system classifies the data. I think, trainPart would be more flexible, though.
2) is this related to the status/processStatus thread we have? basically this is also different versions of a train.

I suggest to discuss those questions in the next developer telco.

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Wed, 26 February 2020 12:00]

Report message to a moderator

Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2414 is a reply to message #2348] Mon, 06 April 2020 11:44 Go to previous messageGo to next message
huerlimann(at)opentrackch is currently offline  huerlimann(at)opentrackch
Messages: 1
Registered: January 2016
Junior Member
Dear Community

I also recommend to keep an information about the priority of a train category in a way. I do not remember why it was defined as a string, but an integer value would also make sense. And as a not so elegant solution an integer in string format (e.g. "3") can be used. I also recommend to use the rule that the lower value means a higher priority.

Best regards

Dani
Re: @categoryPriority of <category> in version 2.5 / Extension of train part [message #2472 is a reply to message #2414] Fri, 26 June 2020 13:38 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior Member
Hi all,

I wanted to update the comunity on what happend regarding this topic; After the last post we discussed this in the TT-developer group. We came to the conclusion that since there actually is usage we will not deprecate this attribute. However we decided that we improve the wiki documentation by adding a best practice description (https://wiki2.railml.org/index.php?title=TT:category). There will be no change to the xsd regarding this issue (thus no trac ticket).

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
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 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
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.
Previous Topic: Continuation: different stop types / Mehrere Betriebshalt-Haltegründe usw.
Next Topic: [railML2] Usage of //ocpTT/times/@scope
Goto Forum:
  


Current Time: Thu Mar 28 19:48:44 CET 2024