Re: Signals vs panels [message #397 is a reply to message #354] |
Wed, 24 October 2012 12:48 |
Christian Rahmig
Messages: 151 Registered: January 2011
|
Senior Member |
|
|
Dear Carsten and other railML users,
> An important question resulting from
>> this modelling brings us back to the initial point of the discussion: How
>> do we model different (functional) types of panels (or signals)? In the
>> example above I packed this information inside the type of the signal
>> aspect. Any comments appreciated...
>
> I think there should be an extension like:
>
> <signal id="s01" pos="42.0" operationalType="main" visibleAtTrack="yes">
> <signalInformation id="s01a010" switchable="true" block="stop"/>
> <signalInformation id="s01a011" switchable="true" block="approach"/>
> <signalInformation id="s01a012" switchable="true" block="clear"/>
> <signalInformation id="s01a020" switchable="true" speed="40"/>
> <signalInformation id="s01a021" switchable="true" speed="60"/>
> <signalInformation id="s01a022" switchable="true" speed="80"/>
> <signalInformation id="s01a023" switchable="true" speed="100"/>
> <signalInformation id="s01a030" switchable="true" direction="F"/>
> <signalInformation id="s01a031" switchable="true" direction="R"/>
> ...
> </signal>
in your example you put the defined signal information in the <signal>
element. Like Susanne, I am not a big supporter of this solution,
because it is more related to the interlocking point of view for the
signal. For the infrastructure it is important to define the signal as a
physical unit, which is situated (with orientation) next to the track.
Therefore I would like to limit the additional signal information to the
various <signalAspect> elements referencing categories of signal
information (like "speed" or "etcs" or "catenary"), which are shown by
this signal.
I created a trac ticket [1], which summarizes the basic idea of the
signal/panel enhancement.
[1] https://trac.assembla.com/railML/ticket/173
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|