Home » railML newsgroups » railML.infrastructure » Schema version 1.00 RC1 released
V1.00 RC1: switchRef/crossingRef [message #99 is a reply to message #98] Tue, 28 September 2004 15:01 Go to previous messageGo to previous message
Matthias Hengartner is currently offline  Matthias Hengartner
Messages: 57
Registered: August 2003
Member
Hello,

I'm fine with the changes and answers in the discussion thread of V.095-02.

There are some little remarks and questions left about V1.0 RC1.

One of them is about switches/crossings on trackBegin/trackEnd (as mentioned
in the discussion thread v.095.02).

In Berlin, we forgot to discuss about the implementation of
switches/crossings which are placed on a <trackBegin>/<trackEnd>. In the
last thread of this newsgroup, I suggested the following:
"I'd prefer to have only a reference to a switch/crossing which is located
in the <connections>-container."

Concretely, I have the following outlined example of a very simple possible
implementation of this idea:

-----------------------------
<track trackID="track1" ...>
<trackTopology>
<trackBegin>
...
</trackBegin>
<trackEnd>
<switchRef elemIDRef="SW01"/>
</trackEnd>
<connections>
<switch elemID="SW01" ...>
<connection connectionID="connection1A"...(to track2,
connection2)/>
<connection connectionID="connection1B"...(to track3,
connection3)/>
</switch>
</connections>
<trackTopology>
</track>
<track trackID="track2" ...>
<trackTopology>
<trackBegin>
<simpleConnection ...>
<connection connectionID="connection2" ... (to track1,
connection1A)/>
</simpleConnection>
</trackBegin>
<trackEnd>
...
</trackEnd>
</track>
<track trackID="track3" ...>
<trackTopology>
<trackBegin>
<simpleConnection ...>
<connection connectionID="connection3" ... (to track1,
connection1B)/>
</simpleConnection>
</trackBegin>
<trackEnd>
...
</trackEnd>
</track>
-----------------------------

Explanations:

- elemIDRef is required and must refer to a switch within the SAME <track>!!
For tracks which begin/end connected to a switch of another track, we have
the <simpleConnection>

- in the example above (and in fact in case in which we use this construct),
we have 3 tracks which are connected in one switch. The switch is defined in
exactly ONE of these tracks (in our example in track1), the other 2 tracks
are connected via simpleConnections.

/ track3
/
/
track1 --------/--------------track2

- analogously, there would be a crossingRef as child of
<trackEnd>/<trackBegin>, which would refer to a <crossing>. analogous to the
previous explanation point, there are normally 4 tracks which are connected
in one crossing, the crossing is defined in exactly ONE of these tracks, and
the other 3 tracks are connected via simpleConnections.

This is a possible modelling. Please tell me your opinion about this.
Especially, I'm not quite sure if it's ok that we have only the attribute
"elemIDRef" in <switchRef>/<crossingRef>. Perhaps, we should include some
attributes like "pos" ore "elemID" there, too. What do you think?


Thanks for your answers and best regards

Matthias Hengartner



------------------------------------------------
Matthias Hengartner
IVT ETH Zürich
++ 41 1 633 31 09
hengartner(at)ivtbaugethzch
------------------------------------------------







"Ulrich Linder" <ULinder(at)RailwaysTU-Berlinde> wrote in message
news:cirfid$b0k$1(at)sifaivifhgde...
> Hello,
>
> the first release candidate of V1.00 is released:
>
> http://www.railml.org/genesis/infrastructure
>
> The handling of switches and crossings is improved. The orientation and
the
> course of a connection is moved from the switch/crossing the the relevant
> "connection"-child. Look at the discussion thread of V0.95-02 for more
> informations about other (minor) changes.
>
> With best regards
>
> Ulrich Linder
>
> ------------------------------
> Dr.-Ing. Ulrich Linder
> Linder Rail Consult
> Mörchinger Str. 25
> D-14169 Berlin
>
> Tel. +49.30.84 72 56 87
> Fax. +49.30.84 47 11 56
>
> Email mailto:UlrichLinder(at)linder-rail-consultde
> www http://www.Linder-rail-consult.de
>
>
>
>
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Schema version V0.95-02 released
Next Topic: V1.00 RC1: overview of open discussion points
Goto Forum:
  


Current Time: Sat Jul 06 12:27:06 CEST 2024