| Re: Missing attributes in the element <switch> [message #232 is a reply to message #230] |
Sat, 09 January 2010 14:19  |
Martin Lehmann
Messages: 3
Registered: November 2009
|
Junior Member |
|
|
The startingt point of this discussion:
>> The element <switch> should have the attributes: "stationOcpRef" and
>> "signalBoxOcpRef". The element <signal> supports these two attributes
>> already. So why does not the element <switch>, too?
Dr. Volker Knollmann aggrees with that point:
> I guess there is definitely an inconsistency between signals and switches.
The simplest solution would be to add the attributes "stationOcpRef" and
"signalBoxOcpRef" to the element <switch>.
But Dr. Volker Knollmann came up with some concerns:
> * There is a possibility to map tracks to OCPs. This is done via
> <trackRef> in the OCP's <propEquip>, IIRC. If implicitly all of the
> track's elements are controlled by the linked OCP then we may NOT
> ADD the attributes to <switch> but we must REMOVE them from <signal>
> as they are redundant to the linking via <trackRef>.
In my opinion, there is a problem in situations similar to the following
example.
Example1:
area OCP1 | area OCP2
o- (entry signal to OCP1)
---------.track1-----------|----track2-------
(entry signal to OCP2) -o |
The entry signal to OCP2 is controlled by the OCP2. In railML the track
element <signal>, which represents the entry signal to OCP2, is located in
the track1. The Problem is the track1 is linked with the OCP1.
Next of Dr. Volker Knollmann concerns:
> * In case we accept the redundancy: are there any other (controlled)
> elements that need a tuple of [station, signalBox] to be fully
> specified? If yes, we should find a common data structure for this
> and find a clean way to implement it. Adding those attributes one by
> one to each element sequentially is NOT a good solution... ;-)
Basicly I do agree. However, it should be considered that some users might
want to reflect only station affiliations but no interlocking affiliations.
> * What is planned for the Interlocking Sub-Schema? Isn't that a better
> place to store the information? I currently don't know...
I do not know what is planned for the Interlocking Sub-Schema, too. Of
course it should be possible to reference the signals and switches from the
interlocking elements. In terms of the regular use of cross-referencing in
RailML the points and signals should link their affiliate signalboxes and
train station, too.
As a conclusion in my opinion the best solution is that the elements
<switch> and <signal> should have the attributes "stationOcpRef" and
"signalBoxOcpRef".
Best regards,
Martin Lehmann
|
|
|
|
Members
Search
Help
Login
Home
