Home » railML newsgroups » railML.infrastructure » V1.00 RC1: open discussion points, part 2
Re: V1.00 RC1: open discussion points, part 2 [message #113 is a reply to message #112] Tue, 26 October 2004 13:09 Go to previous messageGo to previous message
Gregor.Theeg is currently offline  Gregor.Theeg
Messages: 8
Registered: September 2004
Junior Member
Hello,

Thanks to Matthias Hengartner for his ideas. My answer to his suggestions:

> [I guess, these containers (<detectionElements> and
<trainProtectionElements>) are meant to be implemented as children of
> <ocsElements>, right?]

Yes.

> hmm. so far, we (normally) have containers for exactly one type of
> trackElement (e.g. <radiusChanges> with [only] <radiusChange>-elements,
> etc.). Exception: <connections> with <switch> and <crossing>.
> If we introduce (as proposed) a container <detectionElements> with elements
> <detector>, <trackCircuitChange> and later others, this ("unwritten")
> convention is broken.

I would have no problem with introducing 2 containers "detectors" and
"trackCircuitBorders" instead of one container "detectionElements" resp.
"tracksideMagnets" and "balises" instead of "trainProtectionElements". I
think, each of these solutions would work as well as the other.

> 3) introduce new element <detector>
> --> maybe also later?

If nobody urgently needs it, o.k.

> 4) discard attributes "length" and "frequency" of <trackCircuitChange>
> --> question about 2) and 4): do we need <trackCircuitChange> _AND_
> <trackCircuit>? Or wouldn't it suffice to have only <trackCircuit>?

If we define the borders of track circuits within the element
trackCircuit, we usually have to define them twice because a track circuit
border usually limits two track circuits. Another solution would be to
define it once in one of the two adjecting track circuits (Which one?) and
refer to it in the other track circuit. Or we define them outside the
track circuit itself and have 2 references.
A border between track circuits is not always an insulated rail joint.
There are also solutions like S-shaped loops or just limiting the track
circuit by the lenght of the rail. Thus the track circuit borders will get
several attributes. Thus, I prefer to define them as an extra element.

> - in the current scheme, we have the containers <trainProtectionElements>
> _AND_ <balises>. Do you think balises should be reordered as a child of
> trainProtectionElements?

I intended to leave out the container "balises" and to make one container
"trainProtectionElements" which contains balises and tracksideMagnets. But
as mentioned above, we can also have 2 containers instead.

> *** crossings ***

I'm afraid I don't understand well the idea of 0...3 connections. 0
connections are for crossings, 1 for single crossing switches (EKW) and 2
for double crossing switches (DKW), am I right? But 3 connections?
This means that a EKW has 1 connection ID (Right or wrong?), but for
interlocking it needs 2 because it has 2 independent point machines with 2
independent pairs of blades.

Yours
Gregor Theeg

--

Dipl.-Ing. Gregor Theeg
wissenschaftlicher Mitarbeiter
Professur für Verkehrssicherungstechnik
der TU Dresden

Tel.: 0351 / 463 36542
Fax: 0351 / 463 36644
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: railML interlocking
Next Topic: passable connections
Goto Forum:
  


Current Time: Fri May 17 07:55:11 CEST 2024