Home » railML newsgroups » railML.infrastructure » Signals vs panels
Re: Signals vs panels [message #363 is a reply to message #355] Mon, 17 September 2012 20:14 Go to previous messageGo to previous message
Carsten Weber is currently offline  Carsten Weber
Messages: 27
Registered: November 2011
Junior Member
"Susanne Wunsch" <coord(at)commonrailmlorg> schrieb im Newsbeitrag
news:m1ipbkzwi1fsf(at)cygnusheepsaxde...
> "Carsten Weber" <weber(at)irfpde> writes:
>
> 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.
>
So we should not differ the way of signaling in such a high level.

> 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.
>
I hope I wrote it some days before: Some signal aspects belong to both
groups. So what to do? Who needs this groups (for what)? Who brings the
different aspects into predefined groups?
So in my eyes it would not be good to group signal aspects. If you import
signal aspects you do not know .. maybe you do not need them and can skip
them.

> For light signal aspects we need an attribute like "switchable" - I
> agree.
>
This way we do not need to differ between "signals" and panels. The
attribute "switchable" tells us if the aspect is shown as a fixed sign at a
panel. Maybe we can call it also "panel" (yes/no)

> [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).
>
Just some hints at my answer to my own statement.

> 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 can remember long discussions about types of signals at another modeling
group.

> 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.

Of course. But we should avoid redefining this if we know the problems
before defining the xml-model of a signal inside of RailML.

Best regards.

Carsten

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: basic idea of the signal/panel enhancement
Next Topic: Alternative Stationsnamen (ocp, additionalName)
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Tue May 14 01:30:34 CEST 2024