| Re: Signals vs panels [message #355 is a reply to message #354] |
Tue, 11 September 2012 12:25   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hello Carsten and Christian and all others,
"Carsten Weber" <weber(at)irfpde> writes:
> "Christian Rahmig" <coord(at)infrastructurerailmlorg> schrieb im Newsbeitrag
> news:k2f9fo$agl$1(at)sifaivifhgde...
>>> For me it looks better to implement the panels as signals too. So a
>>> signal should contain a subelement "signal aspect(s)" within an
>>> attribute "switchable" which differes between aspects that are fix
>>> (and may be a panel) or aspects which are shown in special
>>> situations. This way you can easily change between panels or boards
>>> and switchable signal aspects without looking at different positions
>>> inside the scheme. So a reading tool only needs to look into signals
>>> and it's subelements signalaspects to find informations given to the
>>> driver/engine. In your case a reading tool has to look into panels
>>> and signals.
>> 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.
I like the idea to aggregate panels and signals. There are lots of
aspects that are sometimes shown with fixed panels and sometimes with
light signals but each time have the same influence on operation.
For offering special attributes in the appropriate context we should
group the signals into functional categories like catenarySignals,
speedSignals, levelCrossingSignals, radioSignals... Pierre Simon already
gave a starting point for this approach, I mean.
For light signal aspects we need an attribute like "switchable" - I
agree.
[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.
I currently don't like to go to deep into the functionality of
interlocking related signals but to think more about a general approach
for defining special signals and panels as asked by Pierre Simon.
Any comments, questions, ideas appreciated...
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Members
Search
Help
Login
Home
