Home » railML newsgroups » railML.infrastructure » [railML2] extension suggestion for the element <state> for working zones
[railML2] extension suggestion for the element <state> for working zones [message #2677] Mon, 08 March 2021 16:26 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
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 messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
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 messageGo to next message
Thomas Nygreen JBD is currently offline  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 messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
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 #2747 is a reply to message #2724] Fri, 04 June 2021 14:55 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

I updated the Trac ticket #395 with the solution proposed in my previous posting. If there are no further objections from your side, solution proposal will be implemented with railML 2.5.

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 #2766 is a reply to message #2747] Fri, 18 June 2021 12:51 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

the first part of the solution (state gets an ID and a repeatable designator) has been implemented. The second part of the solution depends on the introduction of the <area> element, which is not yet finalized (see Trac ticket #393 [1]).

[1] https://trac.railml.org/ticket/393

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 #2792 is a reply to message #2766] Fri, 16 July 2021 14:56 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
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 messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
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 #2814 is a reply to message #2801] Thu, 19 August 2021 12:30 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
I think there is a misunderstanding that working zones (as described above and in ticket #395) are the same as working areas. They are not. Working zones are macroscopic constructon sites that lead to additional run time. Work Areas are microscopic protection areas for the workers. This usually provided by the interlocking. The required attributes for working zones have been placed under workingArea. #395 should be as proposed but with a new sub element <workingZone> in ticket #393.

To the question of different track direction:
Track direction is not relevant. As you can perform run time calculations over a track direction change. The additional run time for the working zone is added to this minimum run time.
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
christian.rahmig is currently offline  christian.rahmig
Messages: 436
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
Previous Topic: [railML2] Adding a new element informationArea to ocp
Next Topic: [railML3] rail3:netElement.relation seems useless
Goto Forum:
  


Current Time: Thu Mar 28 21:26:49 CET 2024