Home » railML newsgroups » railML.infrastructure » railML 2.3 infrastructure extension proposal line sections (railML 2.3 infrastructure extension proposal line sections)
railML 2.3 infrastructure extension proposal line sections [message #1456] Tue, 20 December 2016 18:26 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 154
Registered: March 2016
Senior Member
Dear railML infrastructure forum,
This posting contains the discussion to an extension towards the
trackGroups
In Norway we segment a line into line sections. They consist of either stations (defined from home to home signal) or paths (sections between stations; DE:freie Strecke).
There is a need to define which line section a track belongs to. The idea is to define a line section as a group of tracks.
Thus I have added the new element <NO:lineSection> under <trackGroups>.
<NO:LineSection> has the attributes: @trackRef and @type.
@Type [datatype: enumeration] is preset to "station" or "path", but allows other values, too ("other:").
Re: railML 2.3 infrastructure extension proposal line sections [message #1465 is a reply to message #1456] Mon, 02 January 2017 17:29 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Torben,

Am 20.12.2016 um 18:26 schrieb Torben Brand:
> [...]
> trackGroups
> In Norway we segment a line into line sections. They consist
> of either stations (defined from home to home signal) or
> paths (sections between stations; DE:freie Strecke).
> There is a need to define which line section a track belongs
> to. The idea is to define a line section as a group of
> tracks.
> Thus I have added the new element <NO:lineSection> under
> <trackGroups>.
> <NO:LineSection> has the attributes: @trackRef and @type.
> @Type [datatype: enumeration] is preset to "station" or
> "path", but allows other values, too ("other:").

A line section (or section of line) is a structural unit that is used in
other data models, e.g. RINF (see [1]), too. It can be seen as a
component of a railway line and therefore represents some "meso level of
detail" in the model of the railway network. If there is a need by
several railML use cases (see [2]), I appreciate to integrate the line
section into the railML data model, latest for version 3.

Your proposed structure

<trackGroups>
<NO:lineSection>
</NO:lineSection>
</trackGroups>

looks fine and reasonable. If the community agrees with me, I will hurry
to open a Trac ticket for implementation with railML v3.

The attribute @type (enumeration with "station" and "path") makes sense
as well in those countries that distinguish between station tracks and
path tracks (de: "freie Strecke"). However, it should not be forgotten,
that some countries like the United States of America do not know this
differentiation. Therefore, the attribute @type must remain optional and
allow for other values, too.

The reference to the contained tracks should not be done by an
attribute, but by a sequence of child elements, similar to the current
implementation of track references within the <line> element (see [3]).
This will allow to reference an arbitrary number of tracks. An example
may look like this:

<trackGroups>
<NO:lineSection type="path">
<trackRef ref="tr01" />
<trackRef ref="tr02" />
</NO:lineSection>
</trackGroups>

Are there any further ideas or remarks regarding the usage of the line
section entity? Any comments appreciated...

[1]
http://www.era.europa.eu/Core-Activities/Interoperability/Pa ges/RINF.aspx
[2] http://wiki.railml.org/index.php?title=Dev:Use_cases
[3]
https://www.railml.org/files/download/schemas/2016/railML-2. 3/documentation/railML.html#Link2D3

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: railML 2.3 infrastructure extension proposal line sections [message #1476 is a reply to message #1465] Thu, 19 January 2017 19:28 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Torben and Christian,

> If the community agrees with me, I will hurry
> to open a Trac ticket for implementation with railML v3.

We also distinguish between station tracks and line tracks in other
countries, and we have many railML (IS 2.x) files where one
railML<track> representing a "trough line track" goes through several
stations and such "switches" between line and station track from home
signal to end of station and so on.

Therefore, the requirement of Torben is comprehensible.

But, I am not convinced of (nor happy with) the solution
> <trackGroups>
> <NO:lineSection>
> </NO:lineSection>
> </trackGroups>

First, we should avoid that there is a need to make such distinction (as
Christian wrote: North America...).

Secondly, there may be not "hard" or "exact" definition where a station
begins or ends concerning a <line>. For instance, it may start at the
home signal and end at the shunting limit marker board. On a
double-track line, this may be different locations depending driving
direction or which track is used. So, shouldn't this distinction (if at
all) be made at <track>s rather than <trackGroup>s?

Last, so far, we have avoided creating a construct like a "station" in
railML, by intention! (It is no mistake that you do not find a <station>
in railML so far!) So, the <lineSection> should not lead to the
"accidental definition" of a <station>... which then would many
un-wanted discussions (such as: Why no reference from <lineSection> to
<ocp>? Is it allowed that there is more than one <ocp> in one
<lineSection>?).

Rather, I would prefer to describe exactly what is the functional
(operational?) background behind <lineSection>. So my question would be:
What is the operational background behind it?

With best regards,
Dirk.

---
Am 02.01.2017 um 17:29 schrieb Christian Rahmig:
> Dear Torben,
>
> Am 20.12.2016 um 18:26 schrieb Torben Brand:
>> [...]
>> trackGroups
>> In Norway we segment a line into line sections. They consist
>> of either stations (defined from home to home signal) or
>> paths (sections between stations; DE:freie Strecke).
>> There is a need to define which line section a track belongs
>> to. The idea is to define a line section as a group of
>> tracks.
>> Thus I have added the new element <NO:lineSection> under
>> <trackGroups>.
>> <NO:LineSection> has the attributes: @trackRef and @type.
>> @Type [datatype: enumeration] is preset to "station" or
>> "path", but allows other values, too ("other:").
>
> A line section (or section of line) is a structural unit that is used in
> other data models, e.g. RINF (see [1]), too. It can be seen as a
> component of a railway line and therefore represents some "meso level of
> detail" in the model of the railway network. If there is a need by
> several railML use cases (see [2]), I appreciate to integrate the line
> section into the railML data model, latest for version 3.
>
> Your proposed structure
>
> <trackGroups>
> <NO:lineSection>
> </NO:lineSection>
> </trackGroups>
>
> looks fine and reasonable. If the community agrees with me, I will hurry
> to open a Trac ticket for implementation with railML v3.
>
> The attribute @type (enumeration with "station" and "path") makes sense
> as well in those countries that distinguish between station tracks and
> path tracks (de: "freie Strecke"). However, it should not be forgotten,
> that some countries like the United States of America do not know this
> differentiation. Therefore, the attribute @type must remain optional and
> allow for other values, too.
>
> The reference to the contained tracks should not be done by an
> attribute, but by a sequence of child elements, similar to the current
> implementation of track references within the <line> element (see [3]).
> This will allow to reference an arbitrary number of tracks. An example
> may look like this:
>
> <trackGroups>
> <NO:lineSection type="path">
> <trackRef ref="tr01" />
> <trackRef ref="tr02" />
> </NO:lineSection>
> </trackGroups>
>
> Are there any further ideas or remarks regarding the usage of the line
> section entity? Any comments appreciated...
>
> [1]
> http://www.era.europa.eu/Core-Activities/Interoperability/Pa ges/RINF.aspx
> [2] http://wiki.railml.org/index.php?title=Dev:Use_cases
> [3]
> https://www.railml.org/files/download/schemas/2016/railML-2. 3/documentation/railML.html#Link2D3
>
>
> Best regards
> Christian
>
Re: railML 2.3 infrastructure extension proposal line sections [message #1523 is a reply to message #1476] Mon, 06 March 2017 09:56 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 154
Registered: March 2016
Senior Member
These are my answers to Christian and Dirks comments:

We also distinguish between station tracks and line tracks in other
countries, and we have many railML (IS 2.x) files where one
railML<track> representing a "trough line track" goes through several
stations and such "switches" between line and station track from home
signal to end of station and so on.


To use the suggested new element "line section" tracks would have to be segmented on path/station border. This is comparable to when the track name changes. As this also requires a segmentation of tracks in railML today.


But, I am not convinced of (nor happy with) the solution
> <trackGroups>
> <NO:lineSection>
> </NO:lineSection>
> </trackGroups>

First, we should avoid that there is a need to make such distinction (as
Christian wrote: North America...).

Secondly, there may be not "hard" or "exact" definition where a station
begins or ends concerning a <line>. For instance, it may start at the
home signal and end at the shunting limit marker board. On a
double-track line, this may be different locations depending driving
direction or which track is used. So, shouldn't this distinction (if at
all) be made at <track>s rather than <trackGroup>s?


We should make the value optional so you do not need to use the description if you do not distinguish between path and station, or you do not have an exact border. You can have different borders/border rules per track. You then need to segment the tracks on the border. You could distinguish per direction if you added a direction element to the description. As we do not need this in Norway we have not added it to our extension.

Last, so far, we have avoided creating a construct like a "station" in
railML, by intention! (It is no mistake that you do not find a <station>
in railML so far!) So, the <lineSection> should not lead to the
"accidental definition" of a <station>... which then would many
un-wanted discussions (such as: Why no reference from <lineSection> to
<ocp>? Is it allowed that there is more than one <ocp> in one
<lineSection>?).


Could you refer me to the earlier discussion about not having a station defined? I think it's a great concept to optionally refer to an ocp with an @ocpRef, either on the track or in <NO:lineSection>@type"station" The ocpRef should only go to ocp's of @operationalType"station". This for better orientation in the railML structure. Today the user needs to deduct a tracks ocp reference by other means, like absPos values of the crossSection of the ocp.

In Norway a line section can have multiple ocp's on it.
<NO:lineSection>@type"station" can have either reference to one @operationalType"station","junction", "depot" or "crossover". For @operationalType"station" the line section can also have one or more @operationalType"stoppingpoint" on it.
<NO:lineSection>@type"path" can have no ocp's on it or one or multiple @operationalType"halt","siding"or "blockSignal".

Furthermore I refer to Christian Rahmigs comment on my forum posting for "ocp". Here he mentiones that we do not need to define which tracks are on a path and which are on a station as the <track>@type defines this. The values "connectingTrack" and "sidingTrack" are paths and the values "secondaryTrack",and "stationtrack" are stations. The problem is that, as I read the railML wiki, a main track can be both in a path and in a station.

The documentation would have to be clear about the interface towards the existing sister element <locallyControlledArea>. For instance, in Norway a line section of type "station" is usually, but not always, a local controlled area. Likewise, local controlled areas can be found on track sections on the path. To summarize: it seems to me that there are two different definitions and usage to the two elements.

Rather, I would prefer to describe exactly what is the functional
(operational?) background behind <lineSection>. So my question would be:
What is the operational background behind it?


Relevant use cases:
Network statement, line description (DE:"Streckenbuch"), capacity planning. In Norway different operational rules apply pending if you are on the path or in the station area. Also values could change. For instance a @operationalType"stoppingPoint" changes value to "halt" if it's on the path.
It would help the general orientation in the railML structure by showing which ocp the hundreds of <track>@name"1" belongs to.

Another very useful effect of grouping tracks together and referencing them to an ocp would allow all objects placed on the tracks to be referred to the same ocp by proxy. Many ocsElements need to be ocp referenced. This would make things simpler. If an object by exemption needs to reference to a different ocp, that ocp could be described on the specific object.

Bob Jansen mentioned "Please note that the interlocking schema introduces TVD sections. These shouldn't conflict with line sections.». If there are TVD sections present they correspond roughly to the line sections in Norway. This as the line section border is at a home signal and this usually has a TVD section border associated to it. So the line section suggestion adheres to TVD sections.

To round up the use case: The element lineSection is useful for us, but not essential.
Re: railML 2.3 infrastructure extension proposal line sections [message #1585 is a reply to message #1523] Thu, 18 May 2017 18:30 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Torben,

> We should make the value optional so you do not need to use
> the description if you do not distinguish between path and
> station, or you do not have an exact border. ...

Yes, I know. But the point is: Why defining in railML at all? That's why
on 19.01.2017 I added the question: "I would prefer to describe exactly
what is the functional (operational?) background behind <lineSection>.
So my question would be: What is the operational background behind it?"

> Could you refer me to the earlier discussion about not
> having a station defined?

Sorry I tried but it's difficult because it seems to be spread over
years and not everything is in forum posts.

Anyway, I do not want to convince you from not-getting a reference to an
<ocp>. I myself would prefer it. Only, it is very difficult in general
and so I do only say: If we do it now, we should also define the
operational background. For instance, in railML wiki, provide a
definition of <station> or <lineSection>. To avoid that every country
uses these elements in different semantics.

> I think it's a great concept to
> optionally refer to an ocp with an @ocpRef, either on the
> track or in <NO:lineSection>@type"station"

I agree.

> The ocpRef should only go to ocp's of @operationalType"station".

I do not agree. Blocking signals should be allowed to refer to an <ocp>
of @operationalType='blockPost', for instance.

As you wrote, line-side sidings should be allowed to refer to an <ocp>
of @operationalType<>"station". They must refer to an <ocp> at all
because there may be trains entering, stopping or starting there.

> This for better orientation in the railML structure.
> Today the user needs to deduct a tracks ocp reference by other means, like
> absPos values of the crossSection of the ocp.

Yes. Why should the user need to deduct a tracks <ocp>? This again leads
to the operational background. (To make it clear again: I agree that it
would be helpful to find a solution in railML. But we clarify the usage.
We should avoid misunderstandings and uncontrolled usage.)

> Furthermore I refer to Christian Rahmigs comment on my forum
> posting for "ocp". Here he mentiones that we do not need to
> define which tracks are on a path and which are on a station
> as the <track>@type defines this. The values
> "connectingTrack" and "sidingTrack" are paths and the values
> "secondaryTrack",and "stationtrack" are stations. The
> problem is that, as I read the railML wiki, a main track can
> be both in a path and in a station.

I do not agree with Christian's comment in general. Yes, a main track
can be both in a station and between stations. Also,
<track>@type="connectingTrack" can be between two line-side switches of
a crossover (German "Überleitstelle"). So "connectingTrack" may be
inside and outside stations, same as with "sidings" and others.

May be Christian means that "connectingTrack" is always inside an <ocp>.
If so, I probably would agree. That's why there is the term "ocp" in
railML which is not the same as "station". A crossover (German
"Überleitstelle") is an <ocp> in railML but not a station in Germany.

Do you see the problem? That's why we have to define what we mean with
"station" if we introduce station limits in railML.

Conclusion from my side: I agree with most of your suggestions.

I would agree to assign tracks and track elements optionally to <ocp>s.
If an <ocp> is a station, then the track or track element belongs to
that station. If the <ocp> is no station, the track or track element is
line-side.

I would agree to define station limits if we define what is a station
(at least, in Wiki). Is a German Überleitstelle a station in the sense
of railML or not?

With best regards,
Dirk.
New reflected thoughts towards railML 2.3 infrastructure extension proposal line sections [message #1624 is a reply to message #1456] Fri, 14 July 2017 09:44 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 154
Registered: March 2016
Senior Member
As previously mentioned, the use case for line sections is to segment the line and to group the tracks. The grouping of tracks is an essential feature, as else the <track/trackTopology/borders> can be used. The element shall be optional. The segmentation is free to be defined as the individual model requires. The Norwegian model requires (use case: network statement, the Norwegian line book, the Norwegian asset management database structure) a segmentation into the open section (open track, line-side, NO:"linjen", DE"freihe Strecke" univocal English term to be defined) and the station (according to Norwegian definition).
I agree with Dirk that "station" is not well enough defined in railML nor generic international (in RTM). So it's better to segment according to ocp. As there is already the possibility to reference tracks under an ocp in the sub element <ocp/propEquipment/trackRef> I suggest to use this. As there also is an ocp of propOperationaltype:"station" the result is the same. But the model is probably more consistent.
To model the open section (or other line sections/segment) I suggest to keep the proposed element <lineSection>.
I suggest to change the suggested <lineSection>@type:"path" to "openSection, as this seems to be a better term (but I am, as always, open for other suggestions. Also, I will receive guidance for English terms from Network Rail resources in August). Alternative if no common ground can be found for defining "open section" we suggest to use the national value: "NO:linjen".

An alternative is to make a new <ocp/propOperational>@type:"openSection". But I would prefer the line section choice as an open section is not an ocp and the an open section "ocp" could contain multiple other ocps. What does the forum think?
Re: railML 2.3 infrastructure extension proposal line sections [message #1665 is a reply to message #1585] Mon, 20 November 2017 15:55 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Dirk and Torben,
dear all,

the topic is very relevant for the implementation of railML 3.1.
Therefore, I tried to conclude the discussion and resulting open
questions in a Trac ticket [1].

In order to come to a final solution I would like you to work together
with me on answering the following questions:

(1) What is the (operational) background of a line section? Why is this
element important? What are the attributes required by the <lineSection>?
(2) What is the exact dimension of a line section? Where does it begin
and where does it end?
(3) Is it necessary to define a "station" before specifying line section
dimensions?
(4) Shall the <lineSection> have an attribute @type to specify whether
the line section belongs to a station ("station") or the path ("path")?
(5) Is it allowed to have more than one <ocp> in one <lineSection>?
(6) What is the difference between the (interlocking) related "TVD
section" and the (infrastructure) based line section?

Any feedback from the rest of the community is also highly appreciated...

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

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: New reflected thoughts towards railML 2.3 infrastructure extension proposal line sections [message #1666 is a reply to message #1624] Mon, 20 November 2017 16:05 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Torben,

Am 14.07.2017 um 09:44 schrieb Torben Brand:
> [...]
> To model the open section (or other line sections/segment) I
> suggest to keep the proposed element <lineSection>. I suggest to change
> the suggested <lineSection>@type:"path"
> to "openSection, as this seems to be a better term (but I
> am, as always, open for other suggestions. Also, I will
> receive guidance for English terms from Network Rail
> resources in August). Alternative if no common ground can
> be found for defining "open section" we suggest to use the
> national value: "NO:linjen".

did you already get guidance for English terms from Network Rail? I am
curious to hear/read whether they prefer "openSection" or "path".

>
> An alternative is to make a new
> <ocp/propOperational>@type:"openSection". But I would prefer
> the line section choice as an open section is not an ocp and
> the an open section "ocp" could contain multiple other ocps.
> What does the forum think?

I agree. An operational point is an operational point and the railway
line/track in between can be defined as line section.

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: New reflected thoughts towards railML 2.3 infrastructure extension proposal line sections [message #2745 is a reply to message #1666] Fri, 04 June 2021 08:41 Go to previous messageGo to next message
Morten Johansen is currently offline  Morten Johansen
Messages: 9
Registered: February 2017
Junior Member
Dear all.

Bane NOR have been asked for their need to have an element handling line sections in railML2.5.

In general Bane NOR definitely sees the value and will be dependent of having an element like <lineSection> in railML. This because the line sections in Norway have their own names and number based Ids. Line sections are among other things used in communication within train operations, and in maintenance.

As railML3.x is the main interest for Bane NOR we have no plan to use the railML2.5 version actively. Until the publication of railML3.2 we will be covered by the line section construct defined as part of the Norwegian extention to railML2.4.

Best regards
Morten
Re: New reflected thoughts towards railML 2.3 infrastructure extension proposal line sections [message #2746 is a reply to message #2745] Fri, 04 June 2021 12:35 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Morten, dear all,

following BaneNOR's needs, I adapted the Trac ticket #414 [1] accordingly: I added a solution proposal that is very identical with the railML 3.x solution documented in Trac ticket #316 [2]. The central idea of the solution proposal is to use the element <line> also for line sections. These <line> elements can be aggregated as a complete <line> using new attribute @belongsToParent.

I am looking forward to receiving your feedback on this planned railML 2.5 implementation.

[1] https://trac.railml.org/ticket/414
[2] https://trac.railml.org/ticket/316

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML3] Improvement for railML element „etcsLevelTransition"
Next Topic: [railML2] extension suggestion for the element <state> for open time period
Goto Forum:
  


Current Time: Tue Mar 19 07:16:51 CET 2024