| crossing of 2 continuous tracks [message #143] |
Thu, 03 February 2005 16:39  |
Matthias Hengartner
Messages: 57
Registered: August 2003
|
Member |
|
|
Hello,
Now that we have a "stable" version 1.00, I'd like to come up with an old
topic: How to map the following topology on railML:
/
/
Track1 /
----------+-----------
/
/
/ Track2
(2 continuous, tracks which cross each other).
I copy-paste here my ideas from older postings and supplement them with some
new considerations:
Given the picture above and assuming that Track1 goes from the left to the
right and Track2 from bottom (left) up (right)
So we could have the following implementations in railML:
*** 1 ***
One <crossing> in each <track>, each of them have two <connection>s
referring to a <connection> of the other <crossing>.
---> railML:
in Track1:
<crossing>
<connection connectionID="C1a" branchIDRef="C2b"
branchTrackIDRef="Track2" orientation="outgoing"/>
<connection connectionID="C1b" branchIDRef="C2a"
branchTrackIDRef="Track2" orientation="incoming"/>
</crossing>
in Track2:
<crossing>
<connection connectionID="C2a" branchIDRef="C1b"
branchTrackIDRef="Track1" orientation="outgoing"/>
<connection connectionID="C2b" branchIDRef="C1a"
branchTrackIDRef="Track1" orientation="incoming"/>
</crossing>
When the crossing is a right-angled "simpleCrossing", the orientation would
be "rightAngled", of course.
Advantage of this solution:
1) There is a <crossing>-element in both tracks, so it's "symmetric" and
both
track are treated equally.
2) The current schema could hasn't to be changed
Disadvantages:
1) There are 2 <crossing>-elements for 1 (physical) crossing
*** 2 ***
Only one <crossing> in one <track>. The other Tracks has 2 "internal
connections". These refer to the 2 <connection>s of the <crossing>.
Just outlined:
<track1>
<crossing>
<connection ID="a1" refID="b1">
<connection ID="a2" refID="b2">
<track2>
<internalConnection ID="b1" refID="a1">
<internalConnection ID="b2" refID="a2">
Advantage of this solution:
1) Exactly 1 <crossing>-element for 1 (physical) crossing
Disadvantages:
1) "asymmetric", since the 2 tracks are treated differently
2) The current schema could has to be changed
***
At the moment, I'd prefer the first solution.
Other opinions? Questions? Ideas?
Best regards
Matthias Hengartner
--
****************************
Matthias Hengartner
IVT ETH Zürich
hengartner(at)ivtbaugethzch
++ 41 1 633 68 16
****************************
|
|
|
|
Members
Search
Help
Login
Home
