| Re: Modified V94_12 [message #39 is a reply to message #38] |
Tue, 18 November 2003 20:58   |
nfries
Messages: 6
Registered: November 2003
|
Junior Member |
|
|
Hello,
in my thesis handed in at the TU Dresden in August presenting a new
version of the infrastructure scheme some of your points have been
discussed. I might try to give some propositions from my point of view:
> The most significant change is the introduction of a element called
> <ocsElements>, which is a child of <track>. "ocs" means "operation- and
> controlsystems" and is meant to be a translation of the German "Leit- und
> Sicherungstechnik".... err.... if you know a better translation, feel free
> to tell me :-)
How about "command and control systems"?
> <ocsElements> should contain all objects related to operation, control, train
> protection and similar things. Just to give you an idea, I created
> sub-elements for Balises, track coupling coils, track circuits, LEUs and
> EuroLoops. And I moved the <signals>-Element into this <ocsElements>, of
> course.
What does LEU mean?
Why did you leave <trainProtectionChanges> as an own element?
> The detailed definition, especially the attributes, of the new elements is
> not yet complete. I just want you to get an idea of my changes and if you
> think that I chose a good way, we / I can spend more time on this.
It is for sure a possible solution, although the whole element might get
rather clumsy if you try to cover all technical solutions of communication
between engine and infrastructure. The <signal> element will need further
development in order to be practically applicable.
> Another change is the introduction of the attributes <prevTrackID> and
> <nextTrackID> for the element <track>. With this means, you are able to
> compose a line of multiple tracks similar to a double linked list. Of
> course, <nextTrackID> of one track and <prevTrackID> of the next track
> need to be consistent, otherwise the xml-file would be corrupt.
> These two attributes are just a quick & dirty suggestion. Up to know, I'm
> not really sure whether I really like them myself. To be honest, I'm not
> even sure whether you really need to compose a line of several tracks.
> Background: due to your microscopical model, you only need to define
> special points (swicthes, signals, xxxChange, etc) along the track. This
> can all be done within one track element. This is in contrast to a
> macroscopical model, where to need to compose a "long" track (line) of
> several edges. Therefore, I see the need to compose one line of several
> tracks only for the use of a macroscopical model, not for the use of a
> microscopical model.
Still there might be some occasions where the possibility to connect two
<track> elements will be useful, e.g. if you want to combine to sections
of infrastructure already existing in RailML (analogy to OpenTrack), there
will be the need to refer to the appropriate point in the neighbour model.
In that concern one single attribute "nextTrackId" will not be sufficient
because the point of reference on the given track is not specified.
My version provides a <connection> element containing the attributes
"trackID", "pos" and "dir" (sense of mileage).
Greetings from Paris,
Nikolaus Fries
|
|
|
|
Members
Search
Help
Login
Home
