[railML2] extension suggestion for the element <state> for working zones [message #2677] |
Mon, 08 March 2021 16:26 ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Torben Brand
Messages: 161 Registered: March 2016
|
Senior Member |
|
|
The element <state> is used amongst others for the description of certain characteristics of track and catenary works, collectively refered to as work zones. For track works use <track>/<states>/<state>. For catenary works use <electrificationChange>/<states>/<state>.
There are three items missing in railML2.4 for the UC for working zones:
- enumeration "restricted"
- ID of the working zone
- Additional running time that the working zone inflicts on trains passing through
These works may lead to trains not being able to operate, thus the construction site/ the relevant infrastructure is set to <state>@status=disabled. But the infrastructure works may also only restrict the train operations. Thus, we are missing an enumeration value between "operational" and "disabled". We suggest introducing the new enumeration value "restricted" for this purpose.
The working zone must be identified. Jernbanedirektoratet suggest to add an attribute @restrictionID of type xs:string for "Official reference code for the restriction".
Working zones are usually modelled in a macroscopic and not in a microscopic detailed way. Thus we suggest to add the value of the additional running time for all trains passing through the working zone if set to status="restricted". As the time is direction dependant we suggest to add a sub element <additionalRunningTime> containing:
@time of type xs:duration "Additional running time for trains passing through the restriction area"
@absDir "xs:enumeration "Direction of traffic that the additional time applies to. Possible values are "raising" (misspelling of "rising" inherited from railML2.2) and "falling" "
Working zones are amongst others displayed in the graphical timetable in Norway.
What does the community think about this UC and its solution suggestion?
|
|
|
Re: [railML2] extension suggestion for the element <state> for working zones [message #2696 is a reply to message #2677] |
Fri, 09 April 2021 16:35 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
christian.rahmig
Messages: 455 Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
that is an interesting topic you are bringing up. I see the benefit / use case, but I have some fundamental questions:
1) What is the official reference code for a restriction? Do you have any examples?
2) The additional running time has further input factors beside the direction. How about different train types etc.? How many different additional running times exist for one single working area?
3) What is meant with "ID of the working zone"? Can this information be covered with a designator?
Like Torben, I am curious to hear further opinions and feedback from the community...
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
Re: [railML2] extension suggestion for the element <state> for working zones [message #2722 is a reply to message #2696] |
Fri, 21 May 2021 12:33 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Thomas Nygreen JBD
Messages: 68 Registered: February 2017
|
Member |
|
|
Dear Christian,
I will try to answer based on information provided by Bane NOR last year.
1 and 3) These are the same thing. It is a string identifying each restriction. In Norway it normally takes the form BN-xxxxxx_xxxxxx. You can see a lot of them in the daily graphic timetable (restrictions marked by horisontal and vertical arrows). The use case is to provide this identifier so that it can be displayed on the timetable.
2) This was requested by Bane NOR as an approximate additional time, independent of train type, but possibly depending on direction (hence the @absDir), so the multiplicity is 0..2. The use case is to help planners, by providing an approximate value. The actual restricted speed limit is modelled using <speedChange> with reference to a temporary speed profile.
Best regards,
Thomas
Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
|
|
|
Re: [railML2] extension suggestion for the element <state> for working zones [message #2724 is a reply to message #2722] |
Fri, 21 May 2021 14:05 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
christian.rahmig
Messages: 455 Registered: January 2016
|
Senior Member |
|
|
Dear Thomas, dear Torben,
following your remarks I come to the following conclusions:
1) A <state> should have an identifier or designator to make it adressable and usable e.g. within graphical representations. Currently, a <state> has no ID and no designator.
2) Connecting an "additional running time" with a state of an infrastructure element (e.g. a track) seems to be more some kind of a workaround instead of a proper solution. Why not using an <area> element to explicitly define a construction area, that causes additional running times?
What does the rest of the community think about it?
Best regards
Christian
PS: The whole issue is filed in Trac ticket #395 (https://trac.railml.org/ticket/395)
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
Re: [railML2] extension suggestion for the element <state> for working zones [message #2792 is a reply to message #2766] |
Fri, 16 July 2021 14:56 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
christian.rahmig
Messages: 455 Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
dear all,
based on Trac ticket #395 [1] I implemented the <additionalRunningTime> within <area> as a first version. In that context, the following challenges should be considered in the discussion:
* A direction dependency as modelled with <additionalRunningTime>@dir is not feasible with areas that are not directly linked with tracks, e.g. an information area around an OCP.
* A direction dependency as modelled with <additionalRunningTime>@dir is not feasible with areas that span over several tracks having different directions.
So, we should clarify it once again: for which scenarios the <additionalRunningTime> (with direction dependency) is needed? Can you provide an example? Any comments are highly appreciated...
[1] https://trac.railml.org/ticket/395
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
Re: [railML2] extension suggestion for the element <state> for working zones [message #2801 is a reply to message #2792] |
Fri, 30 July 2021 19:03 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
christian.rahmig
Messages: 455 Registered: January 2016
|
Senior Member |
|
|
Dear all,
following adaptations linked with Trac ticket #393 (re-naming <area> into <genericArea> and introducing <workingArea> etc.) [1] I updated railML 2.5 solution proposal for the additional running time in Trac ticket #395 [2]. Please review and let us know if you discover issues to be discussed / corrected / adapted...
Further, one of the two challenges mentioned in my previous post remains and awaits your qualified feedback:
* A direction dependency as modelled with <additionalRunningTime>@dir is not feasible with areas that span over several tracks having different directions. How to cope with this situation?
Any kind of example or comment is highly appreciated...
[1] https://trac.railml.org/ticket/393
[2] https://trac.railml.org/ticket/395
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Re: [railML2] extension suggestion for the element <state> for working zones [message #2820 is a reply to message #2814] |
Fri, 20 August 2021 17:56 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) |
christian.rahmig
Messages: 455 Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
dear all,
in order to differentiate between the two elements with their different characteristics and application, Thomas and me discussed a renaming. Our proposal looks like this (please also see forum post [1]):
* the microscopic work zone relevant for its integration into interlocking systems shall be modelled as optional, but repeatable child element <workZone> of <controller>. For getting the exact location of the work zone, the referenced <genericArea> provides these information.
* the macroscopic "section of impairment" is a part of a track or a railway line, where due to various reasons (including track works) railway operation is affected, e.g. by extending travel times. These sections are modelled as <impairmentSection> child elements of <track>. Their exact location can be also assessed by following the link to the <genericArea>. In addition, they can be attributed with additional running times.
The proposed solution is documented in Trac tickets #393 [2] and #395 [3]. In case anyone of you has any remarks on this proposal, now is the ftime to do so...
[1] https:// www.railml.org/forum/index.php?t=msg&th=813&goto=281 9&#msg_2819
[2] https://trac.railml.org/ticket/393
[3] https://trac.railml.org/ticket/395
BR
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|