Home » railML newsgroups » railML.infrastructure » [railML 3.1] border types
| [railML 3.1] border types [message #1806] |
Thu, 24 May 2018 18:52  |
christian.rahmig
Messages: 458
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  |
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 #1827 is a reply to message #1810] |
Mon, 04 June 2018 15:25 |
christian.rahmig
Messages: 458
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 |
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 |
Dirk Bräuer
Messages: 313
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 |
Joerg von Lingen
Messages: 149
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 #2694 is a reply to message #2690] |
Fri, 09 April 2021 15:07 |
christian.rahmig
Messages: 458
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 #2727 is a reply to message #2718] |
Fri, 21 May 2021 16:14 |
christian.rahmig
Messages: 458
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
|
|
|
|
Goto Forum:
Current Time: Sat Sep 07 20:39:36 CEST 2024
|
Members
Search
Help
Login
Home
