| Re: Speed Panels: types and reference to <speedChange> [message #415 is a reply to message #408] |
Thu, 01 November 2012 15:01   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi Christian and others,
>>> In the proposed implementation, which is described in trac ticket [2],
>>> the parameter "elementRef" is introduced for the <signalAspect>
>>> element. Depending on the above mentioned boolean parameters defining
>>> the type of the signal aspect, the appropriate infrastructure element
>>> can be referenced, e.g. a <speedChange>.
>>
>> This leads to a very heavy overloaded element "signalAspect" with the
>> possibility to mix topics together that should be better separated.
>>
>> Not to say, that this element can't be validated in any useful
>> manner. No xs:keyref mechanism works here. You may mix catenary
>> information with speed and level crossing related topics. No XML
>> validation shows an error!
>>
>> We should try to better model this topic and define semantically
>> separated elements. No problem to use generic types in the background,
>> but not generic elements in the foreground!
>
> I totally agree with your idea of semantically separated elements. But
> this separation requires definite categories for signal types. As
> mentioned in my post in [1] it is often difficult to exactly link the
> signal with a signal type on a macroscopic level.
>
> So, our task for railML 2.2 is to define these categories and to
> define them in such a way that there won't be any misunderstandings
> when chosing a signal type.
Good idea. Let's start.
> In the trac ticket [2] I proposed the
> following categories and ask for your approval/denial/addition:
>
> - speed,
The main problem is that all "traditional signals" are more or less
"switchable speed signals" for certain ranges.
Maybe we can distinct between "pure fixed speed signals" and "switchable
speed signals" with country-specific signal aspects.
> - etcs,
* Fixed marker boards
* light signals indicating a new movement authority (for ETCS level 1)
* (level crossing signals), likely don't exist
* no balises or balise groups, but they may transfer the "traditional
signal aspect" as "speed restriction for a certain range".
> - levelCrossing,
several kinds of signals for ringing the bell, whistle, announcing,
activating the level crossing ...
> - gsm,
more general: trainRadio
* fixed train radio signals indicating a channel
* fixed GSM signals indicating an GSM-R-equipped area, also the
negation indicating a non-GSM-R-equipped area, maybe with an
attribute to "enter"/"leave", also used for a "radio hole"
> - catenary
* no catenary section
* no current section / main power switch off
* lower pantograph section
* additional signal (de: ICE-Schaltmerkhilfe)
- trainProtectionSystem
* indication a block number (de: LZB-Blockkennzeichen)
- line
* indicating the line number
- milepost (de:Hektometertafel)
* indicating the mileage of a track, often fixed at a pole
- braking
* non-stopping section
* no regenerative braking
* no eddy-current braking
* no magnetic-shoe braking
> - signalingSystem
Currently no idea how to harmonize it in another way than an enumeration
of signal systems with their possible signal aspects.
It can get messy to cover all these special kinds of signals, have a
look at http://www.stellwerke.de for the German, French and Luxemburg
(explanations in German only). But not to characterize them results
messy for the data exchange.
> [1]
> http://www.railml.org/forum/ro/index.php?group=1&offset= 0&thread=54&id=148
> [2] https://trac.assembla.com/railML/ticket/173
Sorry for the detailed lists, I tried to find some examples for the
categories for some better understanding.
Feel free to comment, move the details and categories around, add some
new...
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Members
Search
Help
Login
Home
