Home » railML newsgroups » railML.infrastructure » crossing of 2 continuous tracks
Re: crossing of 2 continuous tracks [message #144 is a reply to message #143] Tue, 08 February 2005 18:02 Go to previous messageGo to previous message
Volker Knollmann is currently offline  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! ;-)
 
Read Message
Read Message
Read Message
Previous Topic: railMLeditor - current standings
Next Topic: <speedChangeGroup>
Goto Forum:
  


Current Time: Sun May 26 11:18:34 CEST 2024