| Re: Speed Panels: types and reference to <speedChange> [message #400 is a reply to message #398] |
Wed, 24 October 2012 16:14   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Christian, Pierre and others,
Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>> the <speedPanel> element within its container <speedPanels> is a special
>> type of a panel and therefore implemented within the <panels> container
>> in <ocsElements> with railML 2.2 as described in the post [1].
>
> in the meantime the ongoing discussion in thread [1] agreed on
> combining signals and panels in the <signal> element. For
> distinguishing between (static) panels and (switcheable) signals the
> boolean parameter "switcheable" has been introduced.
+1
>> 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).
If the above mentioned characteristics are introduced as boolean-typed
attributes, more than one of them may occur. Are there any situations,
where a combination of these characteristics (announcement, execution,
reminder) is shown for the same aspect? I don't mean an announced speed
of 60 kph next to the execution of 80 kph at the same pole.
>> As you correctly mentioned, speed panels may refer to actual speed
>> changes, e.g. at a speed restriction section. I suggest a parameter
>> "speedChangeRef" within the element <speedPanel>, which refers to the ID
>> of a <speedChange> element.
>>
>> However, this concept of referencing other elements may be applied to
>> other types of panels as well. In particular, catenary panels may refer
>> to <electrificationChange> elements or levelcrossing panels can link to
>> <levelCrossing> objects.
>
> 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!
> [1] http://www.railml.org/forum/ro/?group=1&id=148
> [2] https://trac.assembla.com/railML/ticket/173
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Members
Search
Help
Login
Home
