| Re: Speed Panels: types and reference to <speedChange> [message #408 is a reply to message #400] |
Sat, 27 October 2012 10:40   |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hello Susanne and other railML users,
>>> The definition of various speed panel types is a good extension to the
>>> panel concept. It can be either realized by defining a new parameter
>>> "speedPanelType" having the values 'announcement', 'execution' and
>>> 'reminder' or by setting up boolean parameters for each type, i.e.
>>> "announcementPanel",
>>> "executionPanel" and
>>> "reminderPanel".
>
>> With the definition of <signalAspect> sub-elements within <signal>,
>> which may also include panel information, it is useful to rename the
>> boolean parameters into "announcement", "execution" and "reminder" and
>> put them in the <signalAspect> element.
>
> I would appreciate to allow these characteristics only for signals that
> may have an announcement, execution or reminder. That are quite all. I
> know. E.g. "real signals" and "speed signals" (panels). But how about a
> sign for a treadle (de: Schienenkontakt), e.g. at a level crossing? I
> mean, that sign does neither has an "announcement" nor an
> "reminder". ;-) But it needs a link to its infrastructure facility
> (e.g. level crossing).
>
> Therefore I strongly recommend to define sub-elements for the different
> kinds of signals: speed, catenary, level crossing... with its appropriate
> attributes (characteristics).
For the ongoing discussion about the different types of signals to be
defined, please also regard my last post in the forum thread [1].
>> 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. In the trac ticket [2] I proposed the following
categories and ask for your approval/denial/addition:
- speed,
- etcs,
- levelCrossing,
- gsm,
- catenary and
- signalingSystem
[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
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Members
Search
Help
Login
Home
