Home » railML newsgroups » railml.interlocking » Restricted Areas: limitedBy vs. elements inside
Restricted Areas: limitedBy vs. elements inside [message #2091] Sun, 13 January 2019 04:37 Go to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 148
Registered: May 2011
Senior Member
Dear all,

currently a restricted area can be defined by the references to limiting objects
(isLimitedBy) and the references to all track assets inside the area
(trackAssetInRA).

This can be seen as a redundancy which is not really needed. So how would you
define such an area?

--
Best regards,
Joerg v. Lingen - Interlocking Coordinator
Re: Restricted Areas: limitedBy vs. elements inside [message #2095 is a reply to message #2091] Mon, 14 January 2019 13:49 Go to previous messageGo to next message
Thomas Nygreen JBD is currently offline  Thomas Nygreen JBD
Messages: 68
Registered: February 2017
Member
Dear Jörg,

I have a strong preference for using only the <isLimitedBy>s to define the area. This is also the current approach of the Norwegian sector in railML2.4nor. I find that the <trackAssetInRA>s and similarly the <tvdSection>/<relatedToTrack>s are redundant. The latter is also required (one or more). There can easily be a very large number of assets within an RA, resulting in a large number of such references. Through the topology and positioning systems these assets are easily identifiable without direct references.


Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
Re: Restricted Areas: limitedBy vs. elements inside [message #2098 is a reply to message #2095] Wed, 16 January 2019 12:08 Go to previous messageGo to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 86
Registered: March 2016
Member
Dear all,

we discussed this issue on the today telco. The preference for defining areas like work zone or local operation area or
shunting area is to use isLimitedBy only. Thus the trackAssetInArea can be removed as redundant.

However, for permission zones it might be better to name all the elements which are in the "group" (area) of this
special permission. With the now direct linking it would be no problem to have the permissionZone not an instance of
RestrictedArea and thus having different child elements.

Could you please give me your opinion concerning your practise to define each of the particular areas:
- work zone
- local operation area
- shunting zone
- permission zone

Regards,
Jörg von Lingen - Interlocking Coordinator
Thomas Nygreen wrote on 14.01.2019 13:49:
> Dear Jörg,
>
> I have a strong preference for using only the <isLimitedBy>s
> to define the area. This is also the current approach of the
> Norwegian sector in railML2.4nor.
> https://www.railml.org/forum/index.php?t=msg&th=636& start=0&.
> The latter is also required (one or more). There can easily
> be a very large number of assets within an RA, resulting in
> a large number of such references. Through the topology and
> positioning systems these assets are easily identifiable
> without direct references.
>
Re: Restricted Areas: limitedBy vs. elements inside [message #2119 is a reply to message #2098] Sat, 26 January 2019 05:03 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 148
Registered: May 2011
Senior Member
only <isLimitedBy> for RestrictedArea, but <controlledElement> for PermissionZone

Joerg von Lingen wrote on 16.01.2019 12:08:
> Dear all,
>
> we discussed this issue on the today telco. The preference for defining areas like work zone or local operation area or
> shunting area is to use isLimitedBy only. Thus the trackAssetInArea can be removed as redundant.
>
> However, for permission zones it might be better to name all the elements which are in the "group" (area) of this
> special permission. With the now direct linking it would be no problem to have the permissionZone not an instance of
> RestrictedArea and thus having different child elements.
>
> Could you please give me your opinion concerning your practise to define each of the particular areas:
> - work zone
> - local operation area
> - shunting zone
> - permission zone
>
> Regards,
> Jörg von Lingen - Interlocking Coordinator
> Thomas Nygreen wrote on 14.01.2019 13:49:
>> Dear Jörg,
>>
>> I have a strong preference for using only the <isLimitedBy>s
>> to define the area. This is also the current approach of the
>> Norwegian sector in railML2.4nor.
>> https://www.railml.org/forum/index.php?t=msg&th=636& start=0&.
>> The latter is also required (one or more). There can easily
>> be a very large number of assets within an RA, resulting in
>> a large number of such references. Through the topology and
>> positioning systems these assets are easily identifiable
>> without direct references.
>>
Re: Restricted Areas: limitedBy vs. elements inside [message #2631 is a reply to message #2098] Wed, 13 January 2021 05:58 Go to previous message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 148
Registered: May 2011
Senior Member
Dear all,

we had two years ago the discussion about having border points and/or elements inside to define an area. The decision at
that time was to abstain from the elements inside.

At the moment we have only the references to border points somewhere in a network topology. For a human looking on a
schematic it might easy to detect the area defined by these border points. However, a search algorithm going from the
border points through the topology might not succeed finding the uniquely associated area. Especially in complex
networks this may become (nearly) impossible. Has some one of you already experiences with such problem?

There seem to be two ways out of the dilemma:

1) Having again the possibility to name the elements inside.

2) Associate a search direction with the border point. But here the question arise how such direction info shall be
clearly defined.

What is your opinion on the topic?

--
Regards,
Jörg von Lingen - Rollingstock Coordinator

Joerg von Lingen wrote on 16.01.2019 12:08:
> Dear all,
>
> we discussed this issue on the today telco. The preference for defining areas like work zone or local operation area or
> shunting area is to use isLimitedBy only. Thus the trackAssetInArea can be removed as redundant.
>
> However, for permission zones it might be better to name all the elements which are in the "group" (area) of this
> special permission. With the now direct linking it would be no problem to have the permissionZone not an instance of
> RestrictedArea and thus having different child elements.
>
> Could you please give me your opinion concerning your practise to define each of the particular areas:
> - work zone
> - local operation area
> - shunting zone
> - permission zone
>
> Regards,
> Jörg von Lingen - Interlocking Coordinator
> Thomas Nygreen wrote on 14.01.2019 13:49:
>> Dear Jörg,
>>
>> I have a strong preference for using only the <isLimitedBy>s
>> to define the area. This is also the current approach of the
>> Norwegian sector in railML2.4nor.
>> https://www.railml.org/forum/index.php?t=msg&th=636& start=0&.
>> The latter is also required (one or more). There can easily
>> be a very large number of assets within an RA, resulting in
>> a large number of such references. Through the topology and
>> positioning systems these assets are easily identifiable
>> without direct references.
>>
Previous Topic: What is the rationale for multiple <assetsForIL>s?
Next Topic: [railML3]: Referencing between IS and IL
Goto Forum:
  


Current Time: Fri Mar 29 08:29:59 CET 2024