Missing attributes in the element <switch> [message #229] |
Mon, 23 November 2009 11:02 |
Martin Lehmann
Messages: 3 Registered: November 2009
|
Junior Member |
|
|
(German version below)
Hi everybody,
my name is Martin Lehmann. I am studying Transport Engineering at the TU
Dresden, Faculty of Transportation and Traffic Sciences "Friedrich List".
I'm working on my diploma thesis. The task is to implement an interface in
existing software for reading railML infrastructure data. Here I noticed the
following:
Missing attributes in the element <switch>:
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? Consequently, the two
attributes should also appear in the element <switch> because a switch
belongs to a station and a signalbox in the same way like a signal does.
Maybe there's chance to complement before the version 2.0 will be released.
Best regards
Martin Lehmann
------------------------------------------------------------ ----------
German version:
Hallo alle zusammen,
mein Name ist Martin Lehmann und ich studiere Verkehrsingenieurwesen an der
Fakultät Verkehrswissenschaften der TU Dresden. Ich schreibe gerade meine
Diplomarbeit, in der es unter anderem darum geht: Eine Schnittestelle zum
Einlesen von RailML Infrastruktur Daten in eine bestehende Software zu
implementieren. Dabei ist mir folgendes aufgefallen:
Fehlende Attribute im Element <switch>
Das Element <switch> sollte die Attribute: "stationOcpRef" und
"signalBoxOcpRef" besitzen. Das Element <signal> unterstützt die beiden
Attribute. Konsequenterweise sollten die beiden Attribute ebenfalls beim
Element <switch> auftauchen, da eine Weiche in gleicher Weise wie ein Signal
einem Bahnhof und einem Stellwerk zugeordnet ist.
Vielleicht ist ja möglich, dies zu ergänzen bevor die Version 2.0
freigegeben wird.
Mit freundlichen Grüßen
Martin Lehmann
|
|
|
|
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
|
|
|