Home » railML newsgroups » railml.timetable » @categoryPriority of <category> to be declared deprecated in version 2.5
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 previous 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
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Continuation: different stop types / Mehrere Betriebshalt-Haltegründe usw.
Next Topic: [railML2] Usage of //ocpTT/times/@scope
Goto Forum:
  


Current Time: Sun May 05 00:11:17 CEST 2024