Forum: railML.infrastructure » [railML2] adding new element <area> for the mapping of track sections

Home » railML newsgroups » railML.infrastructure » [railML2] adding new element <area> for the mapping of track sections

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

[railML2] adding new element <area> for the mapping of track sections [message #2681]

Fri, 12 March 2021 16:42

Torben Brand
Messages: 156
Registered: March 2016

Senior Member

The Norwegian railway sector has the need to transfer information about the track sections/track vacancy detection areas/track vehicle detection sections formed by track circuit borders or train detectors (axle counters).

As the track section is not always a linear object but can form an area (around switches). We made a generic <area> element in the Bane NOR and Jernbanedirektoratet extension currently used. This as we also had a need for other types of areas in our extension, like a project area (more on this in a separate posting), a local interlocking area and a safe work area provided by the interlocking. The areas are part of the schematic track plan for signalling (SCTP) UC.

For more details see document "railML2.4nor Infrastructure Documentation" (https://www.jernbanedirektoratet.no/railML), version 1.4, 17.12.2020, point 4.9.

Jernbanedirektoratet and Bane NOR are suggesting adding the used nor: extension into railML2.5 as
new <areas> element as child of <infrastructure> with sub element <area> with the following attributes in addition to the common attributes (id, pos, absPos, code, name, description):

@type [xs:enumeration] "Defines the type of area" with values:
"trackSection "Used to describe track sections"
"project" Used to describe the spatial extent of a project area (See separate project posting)
"local" Used to describe a locally operated area in the interlocking
"work" Used to describe work areas in the interlocking
"other:"

@controllerRef [rail:tGenericRef] "Reference to the controller a track section, work or local area belongs to. This attribute is not relevant for project areas."

With sub element <isLimitedBy> with attribute @ref [rail:tGenericRef] "References the borders of the area. The borders of a track section can consist of the following elements: <trainDetector>, <trackCircuitBorder>, <bufferStop> or <openEnd>,. For local and work areas preferably, interlocking elements shall be referenced. The project area is referenced to <border>
In addition, the common <state> sub-element should be included.

Code example:
<areas>
<area description="desc" id="id21" name="Example" type="trackSection">
<isLimitedBy ref="id15" >
<isLimitedBy ref="id16" >
<isLimitedBy ref="id71" >
</area>
</areas>

What does the community think about this suggestion?

[Updated on: Fri, 12 March 2021 17:21]

Report message to a moderator

Re: [railML2] adding new element <area> for the mapping of track sections [message #2691 is a reply to message #2681]

Fri, 09 April 2021 13:08

christian.rahmig
Messages: 436
Registered: January 2016

Senior Member

Dear Torben,

thank you very much for your very detailed solution proposal. I updated the Trac ticket #393 [1] accordingly.

Just one remark or question: What about referencing only <border> elements as area borders in all different cases? The <border> has already a type "area" and fits perfectly in the concept. What does the community think about this proposal?

[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

Report message to a moderator

Re: [railML2] adding new element <area> for the mapping of track sections [message #2717 is a reply to message #2691]

Wed, 19 May 2021 07:47

Torben Brand
Messages: 156
Registered: March 2016

Senior Member

Unfortunately, usage of the existing <border> element is not sufficient for our UC.
This as an area can have:
- further attributes defined only relevant to the area/ambiguous to the borders (like a reference to a controller)
- it can be overlapping (some track section for TVD do this)
- it can reference existing elements that act as borders (like <trackSectionBorder>)

Report message to a moderator

Re: [railML2] adding new element <area> for the mapping of track sections [message #2721 is a reply to message #2717]

Fri, 21 May 2021 12:03

christian.rahmig
Messages: 436
Registered: January 2016

Senior Member

Dear Torben,

the idea was not to replace <area> with <border>, but to limit the types of elements that are referenced via the child element <area / isLimitedBy> to only <border> elements (instead of all the various infrastructure elements). What do you think?

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML2] adding new element <area> for the mapping of track sections [message #2732 is a reply to message #2721]

Fri, 21 May 2021 18:39

Torben Brand
Messages: 156
Registered: March 2016

Senior Member

Christian Rahmig <coord(at)infrastructurerailMLorg> wrote:
> Dear Torben,
>
> the idea was not to replace <area> with <border>, but to
> limit the types of elements that are referenced via the
> child element <area / isLimitedBy> to only <border> elements
> (instead of all the various infrastructure elements). What
> do you think?
>
> Best regards
> Christian

Hi Christian,

Thanks for clarifying. My argument #3 still stands: area/isLimitedBy@ref
should be able to reference existing elements that act as borders (like for
area@type=«trackSection» the reference to <trackSectionBorder> as borders)
This is quite common for ocsElements. I think it would be redundant to have
to model the borders again on top of the ocsElements.

--
TOBR

Report message to a moderator

Re: [railML2] adding new element <area> for the mapping of track sections [message #2735 is a reply to message #2681]

Wed, 26 May 2021 14:55

Thomas Langkamm
Messages: 25
Registered: April 2019

Junior Member

I like the idea very much. We have a very similar problem: We have a customer where we get information about trackroutes via a software interface that gives us a "from" and "to" track section for each trackroute when it's set. These "named track sections" are essentially the fields that light up in the interlocking GUI if a train is inside, I think. They are identical to tvd sections in many cases, but not always: It's possible that several consecutive tvd sections are grouped to one named track section, and it's also possible that one tvd section is divided into several named named track sections (for example if several trains can enter there using permissive driving).

We need to match the data from the interface to our internal model to identify the track routes. Hence we need a way to model these track sections, and link them to track routes, or more correctly link track routes to track sections. (A track route has a start and end track section and optinally a sequence of further track sections for partial trackroute release).

As to the use of "border" points I agree with Torben: My understanding of border points was that they are used to introduce additional points where areas end, points that do not coincide with other infrastructure elements. As our track sections are in most cases bounded by existing railML structures (like axle counters), I think we should reference these existing structures and not introduce additional structures that would essentially be a redundant copy of an axle counter.

Report message to a moderator

Re: [railML2] adding new element <area> for the mapping of track sections [message #2783 is a reply to message #2735]

Sat, 03 July 2021 19:17

Thomas Nygreen
Messages: 66
Registered: March 2008

Member

Dear Torben,
Dear all,

For @type = "project", should the area be linked with a <project> in some way? If so, do you prefer (A) that the <project> lists its <relatedArea>(s) or (B) that each area has a @projectRef (or multiple <projectRef>s if that is an actual use case)? To me, option A seems most in line with the proposed implementation of <project>.

Best regards,
Thomas

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML2] adding new element <area> for the mapping of track sections [message #2785 is a reply to message #2783]

Thu, 08 July 2021 06:34

christian.rahmig
Messages: 436
Registered: January 2016

Senior Member

Dear all,

I updated the railML 2.5 solution proposal in Trac ticket #393 [1] according to all received feedback. This is how it looks like:

A new element <areas> shall be added in <infrastructure>. This shall be the container for an arbitrary number of <area> elements.

The element <area> shall have the common attributes: @id, @pos, @absPos, @code, @name, @description.

The element <area> shall have an attribute @type with the following enumeration values:
* "trackSection" - a track section area (track vacancy detection)
* "project" - an area used for a certain project (e.g. construction)
* "local" - a locally operated area in interlocking
* "work" - a work area in interlocking
* "information" - an area used for passenger information systems
* "other" - any other type of area...

The element <area> shall have an optional attribute @controllerRef to reference the controller that belongs to the area. This attribute is not relevant for project areas.

The element <area> shall have an optional, but repeatable child element <limitedBy> to reference the borders of the area marked by different infrastructure elements.
* The borders of a track section can consist of the following elements: <trainDetector>, <trackCircuitBorder>, <bufferStop> or <openEnd>.
* For local and work areas preferably, interlocking elements shall be referenced.
* The project area is limited by elements of type <border>

The element <area> shall have an optional child element <state> that can be used to define the (operational) state of the area.

The element <area> shall have different options for specifying its location (and thus, its shape) summarized in an optional child element <location>. It contains a choice of:
* a <circle> given by center point <center> (tGeoCoord) and @radius (tLengthM)
* a <polygon> given by at least 4 points <point> (tGeoCoord) where the first and last point are identical to close the area.
* a <trackLocation> with repeatable child elements <trackRef> with attributes @ref (required), @fromPos and @toPos (tLengthM)

This is your chance for final comments on the proposed solution before it goes live with railML 2.5...

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

Thank you very much and best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML2] adding new element <area> for the mapping of track sections [message #2813 is a reply to message #2785]

Thu, 19 August 2021 12:22

Torben Brand
Messages: 156
Registered: March 2016

Senior Member

As I understand it, this solution suggestion for this post has been merged/partially replaced by the suggestion in the posting for an "informationArea" [ https://www.railml.org/forum/index.php?t=msg&th=813& goto=2733&#msg_2733] as reflected in ticket #393. I suggest to close this post and, if needed, continue the dicussion in the post for "informationArea"

Report message to a moderator

Re: [railML2] adding new element <area> for the mapping of track sections [message #2816 is a reply to message #2813]

Fri, 20 August 2021 13:19

christian.rahmig
Messages: 436
Registered: January 2016

Senior Member

Torben Brand wrote on Thu, 19 August 2021 12:22

As I understand it, this solution suggestion for this post has been merged/partially replaced by the suggestion in the posting for an "informationArea" [ https://www.railml.org/forum/index.php?t=msg&th=813& goto=2733&#msg_2733] as reflected in ticket #393. I suggest to close this post and, if needed, continue the dicussion in the post for "informationArea"

Correct. Let's fuse the discussions and continue in the other thread.

BR
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Previous Topic:	[railML2] Adding a new element <turningResistance> to <ocp>
Next Topic:	[railML2] Adding a new element informationArea to ocp

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Tue Apr 16 06:59:48 CEST 2024