| Re: Signals vs panels [message #349 is a reply to message #345] |
Thu, 06 September 2012 10:25   |
Carsten Weber
Messages: 27
Registered: November 2011
|
Junior Member |
|
|
"Christian Rahmig" <coord(at)infrastructurerailmlorg> schrieb im Newsbeitrag
news:k1spas$1ro$1(at)sifaivifhgde...
> Hello Pierre,
>
>> There should be a discussion about the semantics of « signals » and
>> “panels” / switchable or fixed aspects / distinction by an attribute
>> value or by by element names.
>> A future <panels> may hold all types of panels, e.g. speedPanels. Those
>> panels should get a trackside attribute (information important because
>> they are physically installed on the track).
>> - <LevelCrossingPanels>
>> - <catenarySectioningPanels>
>> - <currentPanels>
>> - <pantographPanels>
>> - <fixedSignalingChangePanels>
>> - <linePanels>
>> - <gsmPanels>
>> - <radioPanels>
>>
>>
>> New type of element should be added in the standard to describe the
>> panels
>> from the infrastrucure of the railway.
>>
>> [de: Wie koennen variable Signale und fixe Signaltafel in railML
>> unterschieden werden? Eine Liste moeglicher Signaltafeln wurde oben
>> vorgeschlagen. ]
>
> yes, you are right. Currently, the panel elements are not modelled within
> the railML infrastructure schema. However, their functionality often
> relates to signals and therefore, panels should be added to the
> <ocsElements> container. Since several types of panels exist, I suggest to
> distinguish between them by using sub-elements. The syntax would be:
>
> <ocsElements>
> <panels>
> <speedPanels>
> <speedPanel id="pan1" />
> ...
> </speedPanels>
> </panels>
> </ocsElements>
>
> These may be panel types we may define:
> - <speedPanels>
> - <etcsPanels>
> - <levelCrossingPanels>
> - <gsmPanels>
> - <catenaryPanels>
> - <signalingSystemChangePanels>
>
> <catenaryPanels> may include the <currentPanels> and <pantographPanels>
> that you suggested, or what is your reason for distuingish between these
> types? Plese specify the content and the usage of <linePanels>.
>
> Because, <panels> will be an optional element within the <ocsElements>
> container, we may implement it with the upcoming railML 2.2. Therefore it
> is important to hear and read the other users' opinions on this topic and
> eventually extend this first approach. Any comments appreciated...
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.
Another thing is kept in the grouping of signal aspects. This might only be
useful if anybody defines it for RailML(R). Anything else might be a wild
mixture of positioning signal aspects into different groups as seen from the
software creator and not from a railway scope.
Best regards.
Carsten
|
|
|
|
Members
Search
Help
Login
Home
