Home » railML newsgroups » railML.infrastructure » [railML 3.1] border types
[railML 3.1] border types [message #1806] Thu, 24 May 2018 18:52 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

the functional infrastructure element <border> shall be used to describe
a border point between different "zones", e.g. between railway networks
operated by different infrastructure managers.

Further border types are:
* area (quite general)
* country (border between different countries)
* state (border between different states within one country)
* station (border between railway line and station)
* tariff (border between different tariff zones)

My questions to all of you:
* Is this list of border types complete?
* Which border types do you need from your application perspective?
* Which other parameters are essential for you to describe the border point?

Thank you for your contributions!

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 3.1] border types [message #1810 is a reply to message #1806] Tue, 29 May 2018 18:45 Go to previous messageGo to next message
Thomas Nygreen JBD is currently offline  Thomas Nygreen JBD
Messages: 68
Registered: February 2017
Member
In Norway we discussed just a week or two ago if <border>s were suitable for specifying shunting areas etc. in stations. Would this kind of use be in line with what the element is intended for? Two questions we had was how to group borders together to actually form an area, and how to specify what kind of area it is. The former can be solved by using a common name for all borders of the same area, and the latter by using type="other:...", but creating a way to group borders together by IDREF seems preferable.

This is also one of the elements where it is difficult to understand the semantics of the dir attribute. Can a border exist in only one direction?


Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
Re: [railML 3.1] border types [message #1819 is a reply to message #1810] Sat, 02 June 2018 17:21 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 148
Registered: May 2011
Senior Member
Hi,

if you have something in mind which is temporarily in use and
activated/deactivated by an interlocking then it shall be defined in
interlocking schema. There we have thought about "RestrictedAreas" especially for:
- Working zones
- local shunting areas
- ETCS shunting areas
- permission zones


Dr.-Ing. Jörg von Lingen - Interlocking scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 351 87759 40; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
On 29.05.2018 18:45, Thomas Nygreen wrote:
> In Norway we discussed just a week or two ago if <border>s
> were suitable for specifying shunting areas etc. in
> stations. Would this kind of use be in line with what the
> element is intended for? Two questions we had was how to
> group borders together to actually form an area, and how to
> specify what kind of area it is. The former can be solved by
> using a common name for all borders of the same area, and
> the latter by using type="other:...", but creating a way to
> group borders together by IDREF seems preferable.
>
> This is also one of the elements where it is difficult to
> understand the semantics of the dir attribute. Can a border
> exist in only one direction?
Re: [railML 3.1] border types [message #1827 is a reply to message #1810] Mon, 04 June 2018 15:25 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Thomas,

Am 29.05.2018 um 18:45 schrieb Thomas Nygreen:
> In Norway we discussed just a week or two ago if <border>s
> were suitable for specifying shunting areas etc. in
> stations. Would this kind of use be in line with what the
> element is intended for? Two questions we had was how to
> group borders together to actually form an area, and how to
> specify what kind of area it is. The former can be solved by
> using a common name for all borders of the same area, and
> the latter by using type="other:...", but creating a way to
> group borders together by IDREF seems preferable.

the situation that you describe here, is better being solved with a
different implementation: Instead of using border elements, I suggest to
define an <OperationalPoint> and to locate this operational point as an
area covering all the affected tracks. Further, this <OperationalPoint>
can be specified with an attribute
<propOperational>@operationalType="shuntingYard". Finally, the
interlocking element may reference this operational point.

So, to conclude: I think that grouping of borders is not the best
solution here. Borders shall be used where there is an explicit point
(e.g. on the track) where e.g. the ownership changes (without knowing
where else it will change too).

> This is also one of the elements where it is difficult to
> understand the semantics of the dir attribute. Can a border
> exist in only one direction?

Interesting question. Usually. a border point should be always valid in
both directions. But let's think of a station: the border between
station and "free line" may differ depending on the driving direction:
when entering the station, the entry signal mark a border point. When
leaving the station, the last switch may be seen as border point.
However, I am not the expert in these details and therefore I am happy
about any further comment from the community w.r.t. this issue.

Thank you very much and 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 3.1] border types [message #1828 is a reply to message #1827] Thu, 07 June 2018 16:56 Go to previous messageGo to next message
Thomas Nygreen JBD is currently offline  Thomas Nygreen JBD
Messages: 68
Registered: February 2017
Member
christian.rahmig wrote on Mon, 04 June 2018 15:25

Am 29.05.2018 um 18:45 schrieb Thomas Nygreen:
> In Norway we discussed just a week or two ago if <border>s
> were suitable for specifying shunting areas etc. in
> stations. Would this kind of use be in line with what the
> element is intended for? Two questions we had was how to
> group borders together to actually form an area, and how to
> specify what kind of area it is. The former can be solved by
> using a common name for all borders of the same area, and
> the latter by using type="other:...", but creating a way to
> group borders together by IDREF seems preferable.

the situation that you describe here, is better being solved with a
different implementation: Instead of using border elements, I suggest to
define an <OperationalPoint> and to locate this operational point as an
area covering all the affected tracks. Further, this <OperationalPoint>
can be specified with an attribute
<propOperational>@operationalType="shuntingYard". Finally, the
interlocking element may reference this operational point.


A shunting yard is something else than what I am trying to describe. What we would like to do is to define areas within stations for different interlocking purposes. So Jörg is correct. Two common uses would be for defining areas that can be released from the interlocking for manual operation (probably fits locallyControlledArea in railML 2.x, except that it requires tracks to be split at the borders) or areas that are electrically separated in the signalling system, such that one can be shut down for maintenance without shutting down the whole station. It is too long since I looked at the railML 3 specs to remember if there are other groupings that work better.

christian.rahmig wrote on Mon, 04 June 2018 15:25

So, to conclude: I think that grouping of borders is not the best
solution here. Borders shall be used where there is an explicit point
(e.g. on the track) where e.g. the ownership changes (without knowing
where else it will change too).


I agree that grouping borders is not the best solution. It might be that my mind is to occupied at the moment with solving our needs using the elements that are already in railML 2.x.

Best regards,
Thomas Nygreen


Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
Re: [railML 3.1] border types [message #1920 is a reply to message #1806] Tue, 21 August 2018 18:10 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Christian,

currently, we only use <ocp>.<propService>.tariffpoint in an unspecified way but no <border> element.

However, there may be some demand to model areas with borders for statistic purposes, to using this in railML is planned for the future with a lower priority from our side.

But if we would do so, we would use it in a much more generic way. We would not be able to link areas and borders with countries, states or tariff zones. There is too much arbitrariness concerning this in practice. So we would only need "areas" of different "levels" which meet each other at "borders". In each level, areas cannot overlap but we could have unlimited levels. Whether a level is a country, state or tariff zone we do not know. There are much more levels imaginable but I think we cannot describe them in railML.

Some instances:
There are more administrative border types (levels) than "countries" and "states". In many countries, there are districts our counties. In Saxony (and some other German "free states"), there are "[Regirungsamts]Bezirke". There may be sub-authorities (Bestellerorganisationen) of federal authorities (Aufgabenträger) whose borders are not identical to the districts in spite of, by law in Germany, the districts (Kreise und kreisfreie Städte) are responsible for the local public transit... This all leads to a nearly inscrutable nightmare of borders.

There is a border between Germany and Czech Republic. This border crosses the railway line Plauen - Cheb _several_ times. But depending on the level of administration, not all of these border-crossings are the same: For operational purposes like Zuglaufmeldungen, there is (a.f.a.i.k.) only one border-crossing. For legal purposes in a strict sense (police, prosecution), surely all border-crossings count. There may be many graduations between them: Who maintains tracks and ballast in the short Czech sections north-west of Bad Brambach? Who pays property taxes for that (if anyone)? ;-)

So, to come back to your questions:

> * Which border types do you need from your application perspective?
> * Which other parameters are essential for you to describe the border point?
> * Is this list of border types complete?

More than. In my opinion, for railML, it's already too many because as my examples should show, you can possibly not capture all aspects of borders. So, I would prefer a much more simple and generic model.

With best regards,
Dirk.
Re: [railML 3.1] border types [message #1925 is a reply to message #1828] Sun, 26 August 2018 08:57 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 148
Registered: May 2011
Senior Member
In interlocking schema of railML3 we will have two different ways to reflect
these needs:

1) RestrictedArea: It can be defined as LocalOperationArea with elements inside,
elements as border and elements released for local operation.

2) ElementGroup: For an interlocking (SignalBox) a group of element can be
defined which are operated together like setting a group of signals to stop
aspect. Although the group type "catenary" just not yet exists it can be easily
added.

Best regards,
Joerg v. Lingen

Rollingstock Coordinator

On 07/06/2018 16:56, Thomas Nygreen wrote:
> christian.rahmig wrote on Mon, 04 June 2018 15:25
>> Am 29.05.2018 um 18:45 schrieb Thomas Nygreen:
>>>   In Norway we discussed just a week or two ago if
>>> <border>s
>>>   were suitable for specifying shunting areas etc.
>>> in
>>>   stations. Would this kind of use be in line with
>>> what the
>>>   element is intended for? Two questions we had was
>>> how to
>>>   group borders together to actually form an area,
>>> and how to
>>>   specify what kind of area it is. The former can be
>>> solved by
>>>   using a common name for all borders of the same
>>> area, and
>>>   the latter by using type="other:...", but creating
>>> a way to
>>>   group borders together by IDREF seems preferable.
>>
>> the situation that you describe here, is better being
>> solved with a different implementation: Instead of using border
>> elements, I suggest to define an <OperationalPoint> and to locate this
>> operational point as an area covering all the affected tracks. Further, this
>> <OperationalPoint> can be specified with an attribute
>> <propOperational>@operationalType="shuntingYard".
>> Finally, the interlocking element may reference this operational
>> point.
>
>
> A shunting yard is something else than what I am trying to
> describe. What we would like to do is to define areas within
> stations for different interlocking purposes. So Jörg is
> correct. Two common uses would be for defining areas that
> can be released from the interlocking for manual operation
> (probably fits locallyControlledArea in railML 2.x, except
> that it requires tracks to be split at the borders) or areas
> that are electrically separated in the signalling system,
> such that one can be shut down for maintenance without
> shutting down the whole station. It is too long since I
> looked at the railML 3 specs to remember if there are other
> groupings that work better.
>
> christian.rahmig wrote on Mon, 04 June 2018 15:25
>> So, to conclude: I think that grouping of borders is not
>> the best solution here. Borders shall be used where there is an
>> explicit point (e.g. on the track) where e.g. the ownership changes
>> (without knowing where else it will change too).
>
>
> I agree that grouping borders is not the best solution. It
> might be that my mind is to occupied at the moment with
> solving our needs using the elements that are already in
> railML 2.x.
>
> Best regards, Thomas Nygreen
Re: [railML 3.1] border types [message #2690 is a reply to message #1925] Fri, 09 April 2021 09:57 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
I suggest adding the border type "project" to the list.

This also for railML 2.5

A project border defines the outer limits of a project area. The project area can be defined as the area where either changes are made to the infrastructure based on a specific project or an area that is relevant for a specific project.

In its simples form the project area can be defined only by its borders. In a more precise manner, a project border can form an area (see also posting for an "area" element extension under railML2.5 https://www.railml.org/forum/index.php?t=msg&th=804& start=0& , already available in railML3.1).

In both these cases the project can only be described through the name and/or description attributes. With a reference by the proposed project metadata element (See posting in misc https://www.railml.org/forum/index.php?t=msg&th=805& start=0&) the project can be defined more precise.

For more details see document "railML2.4nor Infrastructure Documentation" (https://www.jernbanedirektoratet.no/railML), version 1.4, 17.12.2020, point 4.13.
Re: [railML 3.1] border types [message #2694 is a reply to message #2690] Fri, 09 April 2021 15:07 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Torben,

for railML 2.5 it is proposed to have a (generic) area element and to define the area borders using references from this area element to <border> elements of type "area". This means, that a border of a project area is modelled in the same manner like a border of a working area.

So, the question is: Is it necessary ot distinguish between different area type borders or is it sufficient to distinguish between different types of areas inside an <area> element? What is the added value of writing <border type="project"> instead of <border type="area"> when the referenced object (<area> element) is the same?

Any opinions from the community are highly appreciated.

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML 3.1] border types [message #2718 is a reply to message #2694] Wed, 19 May 2021 07:52 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
When using the (in railML2.5 suggested new in railML3 exisiting) element <area> with type="project" this would be redundant. but as the use of border@type is mandatory, we suggest to use the existing type="area" to reference to the area, when in use.

But you can also have the need to define stand-alone project borders without an area (when an area is open or not defined clearly). So we still suggest to introduce the new value border@type="project".
Re: [railML 3.1] border types [message #2727 is a reply to message #2718] Fri, 21 May 2021 16:14 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Torben, dear all,

thank you for your feedback. The modification has been implemented in railML 2.5 schema as described in Trac ticket #418 [1].

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

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: [railML2] adding an attribute for clearance on switches and crossings.
Next Topic: railML 2.3 infrastructure extension proposal tunnel resistance factor
Goto Forum:
  


Current Time: Thu Mar 28 23:23:45 CET 2024