| 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
****************************
|
|
|
|
| Re: crossing of 2 continuous tracks [message #144 is a reply to message #143] |
Tue, 08 February 2005 18:02  |
Volker Knollmann
Messages: 32
Registered: October 2003
|
Member |
|
|
On 03.02.2005 16:39, Matthias Hengartner wrote:
> 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
>
> [...]
>
> At the moment, I'd prefer the first solution.
Yes, basing on the current version, I'd agree.
> Other opinions? Questions? Ideas?
Well, what I don't like about the first solution is the flood of
<connection>-elements which are provoked. Theoretically they are not
neccessary, since no track starts or end at a crossing. It's just that
accidently two tracks share the same physical position.
So what if we just declare this physical point? I could be similar to
the following code (let's call it "Version 3"):
<track1>
<crossing pos="InsertRelativePositionOnTrack1Here" crossingTrackId="2"
crossingLineID="42"
crossingTrackPos="InsertRelativePositionOnTrack2Here"/>
</track1>
<track2>
<crossing pos="InsertRelativePositionOnTrack2Here" crossingTrackId="1"
crossingLineID="42"
crossingTrackPos="InsertRelativePositionOnTrack1Here"/>
</track2>
Additionally, we could introduce a kind of "length"-attribute for the
crossing. Thus, a collision of two trains at a crossing could be
detected (very much like a level crossing).
Advantages of version 3:
* Tracks are continuous at crossings, just like in real life. No
<connection>-flood (IT-Freaks would think of a SYN-Flood here, :-D)
* Easy implementation
Disadvantages:
* Two <crossing>-elements for one real crossing; redundancy; possible
inconsistency
* Not compatible with V1.0
Looking forward to your comments,
Volker Knollmann
P.S.: I just found out that I have an urgent appointment in Braunschweig
on March 9, so that I cannot come to the RailML-Meeting... perhaps I can
shift that appointment to one of my colleagues... I'd rather like to
visit Zürich eeeeeeh the railML-conference! ;-)
|
|
|
|
| Re: crossing of 2 continuous tracks [message #145 is a reply to message #144] |
Wed, 09 February 2005 11:37 |
Matthias Hengartner
Messages: 57
Registered: August 2003
|
Member |
|
|
Hello,
> Well, what I don't like about the first solution is the flood of
> <connection>-elements which are provoked. Theoretically they are not
> neccessary, since no track starts or end at a crossing. It's just that
> accidently two tracks share the same physical position.
> So what if we just declare this physical point? I could be similar to
> the following code (let's call it "Version 3"):
I partly agree with you. But: For a "simple" <switch> we have 2
<connection>-elements, so it would be not so farfetched if we have 4
<connection>s for a double-switch-crossing. Nevertheless I agree with you
that it's not necessary to have redundant and partially useless elements and
data just for purposes of datastructure consistency...
>
> <track1>
> <crossing pos="InsertRelativePositionOnTrack1Here" crossingTrackId="2"
> crossingLineID="42"
> crossingTrackPos="InsertRelativePositionOnTrack2Here"/>
> </track1>
>
> <track2>
> <crossing pos="InsertRelativePositionOnTrack2Here" crossingTrackId="1"
> crossingLineID="42"
> crossingTrackPos="InsertRelativePositionOnTrack1Here"/>
> </track2>
>
> Additionally, we could introduce a kind of "length"-attribute for the
> crossing. Thus, a collision of two trains at a crossing could be
> detected (very much like a level crossing).
This version would be nice for simple-crossings, but for switch-crossings it
would be useful (or even necessary) to have the possibilities + attributes
of <connection>-elements.
How about combining versions 2&3?
We could use <connection>-elements for switch-crossings and do without them
for single-crossings. And we could introduce some/all of the proposed
attributes in version 3 for single crossings.
Best regards,
Matthias
****************************
Matthias Hengartner
IVT ETH Zürich
hengartner(at)ivtbaugethzch
++ 41 1 633 68 16
****************************
|
|
|
|
Members
Search
Help
Login
Home
