| Re: Signals vs panels [message #407 is a reply to message #355] |
Sat, 27 October 2012 10:20   |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Dear Susanne and other railML friends,
> [interlocking related signal attributes snipped]
>
>> Depending on the details you want to bring into RailML you might need
>> a third level of modelling signals. It is positioned between signal
>> and signalInformation and groups the signal informations into a
>> "frame" (or something like this).
>
> One approach is the construction based. Another would be from the
> GIS-related world: Define the signals by its types and function-based
> attributes without saying how they look like and how they are joined on
> the same pole (mast?). Then define the construction (assembling?) like
> pole, hight, distance from track and refer the signals there. This is
> just a thought and I would be interested in the pros and cons of both
> approaches and totally different approaches.
considering the discussion in this and related forum threads, I think
that the GIS-related solution of separating the signals' physical
assembling and their operational functionality is the best way of
implementation. Although this approach sounds like railML 3.0, I want to
give an idea of that separation regarding some of the discussed parameters:
[signal construction]
- position along the track
- coodinates
- type of assembling (pole, bridge...)
- height
[operational signal]
- reference to signal construction
- signalling system
- name of the signal (e.g. A12)
- signal frames (main, additional...) containing several signal
information elements
- signal information:
- switcheable vs. panel
- the shown signal aspect (e.g. speed=40)
- valid for train movements (train, shunting...)
- reference to infrastructure element (e.g. level crossing)
The original post opening this thread asked for a more detailed
definition of various types of signals, whereas the word "type" refers
to the operational view of a signal. As already mentioned by Carsten, it
is sometimes difficult to exactly define a signal type on a macroscopic
scale. At the level of "signal information" it should always be possible.
So, to summarize the problem: we either want to exactly distinguish
between different types of signals, which somehow require to define
operational signals, or we allow for interpretations of the
(macroscopic) signal types in combination with the current signal
implementation? What's your opinion, Susanne, Carsten, Pierre?
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Members
Search
Help
Login
Home
