Home » railML newsgroups » railML.infrastructure » [railML 3] Areas in railML 3
Re: [railML 3] Areas in railML 3 [message #2839 is a reply to message #2837] Sun, 17 October 2021 06:07 Go to previous messageGo to previous message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 87
Registered: March 2016
Member
Dear all,

it looks a good idea to bring area objects on the topology level defined by
netElements and combing them with general attributes. However, our railML model
is built up that IL elements link to IS elements which are linking to
netElements in topology but not vice versa. If we now have only the netElements
for defining the constrains of an area, we would need a clever way to search for
the functional elements contained within. Especially for (conventional)
interlocking purpose the location of elements in terms of km x.y or even
coordinates are less important.

Interlocking areas: It is not that easy to bring them all together as they have
different functions behind and therefore different needs to be considered. Quite
often there is the issue of defining the protection from the inside and the
outside. Sometimes we need to define the status of elements within, e.g.
released for local operation or not. These are all functional needs, which
cannot be defined in the infrastructure itself.

ETCS is a kind of Janus head. It uses interlocking functions without really
considering the normal interlocking elements. Thus it is more focused on some
infrastructure features like exact location.

We may have a similar way of defining the basics of an area but I don't think we
can press them in one <genericArea> element.

Best regards,
Joerg v. Lingen - Interlocking Coordinator
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: [railML3] switch reference point
Next Topic: [railML 2] ocp modeling
Goto Forum:
  


Current Time: Sat May 04 08:50:49 CEST 2024