Home » railML newsgroups » railML.infrastructure » Offene Fragen zu Version 0.94_12
Offene Fragen zu Version 0.94_12 [message #35] Thu, 13 November 2003 15:27 Go to next message
volker.knollmann is currently offline  volker.knollmann
Messages: 9
Registered: November 2003
Junior Member
Hallo Newsgroup,

Matthias Hengartner und ich haben per Mail ein paar Fragen zur Version
0.94_12 diskutiert, die wir euch nicht vorenthalten wollen. Wir geben
daher hier den bisherigen Diskussionsverlauf wieder und hoffen auf rege
Beteiligung der anderen!

Meine Fragen an Matthias waren:

- Bezieht sich das Attribut "pos" auf die externe Kilometrierung (ist es
also ein Wert zwischen "kmBegin" und "kmEnd") oder ist es ein Wert relativ
zum Gleisanfang? Früher, in der Version 0.93, gab es ja intPos und
extPos... da war die Namensgebung eindeutiger (obwohl dadurch Werte
redundant abgelegt werden konnten, was mich immer skeptisch macht. Daher
begrüße ich die Darstellung in der Version 0.94_12)

- Wie kombiniere ich mehrere "track"-Elemente (also den Inhalt von
"tracks") zu einer "line"? Ist da alleine die Kilometrierung
ausschlaggebend? Oder schlicht die Reihenfolge in der XML-Datei? Oder soll
das aus den IDs abgeleitet werden? Noch provozierender gefragt: Wozu
brauche ich überhaupt mehrere "track"-Elemente?

Außerdem stand noch meine alte Frage im Raum, wie man Balisenpositionen am
besten ablegen kann. Ich kann vorwegnehmen, dass Matthias und Daniel
Hürlimann sich darüber nochmal Gedanken machen wollen.

Gruß aus Braunschweig,
Volker Knollmann
Re: Offene Fragen zu Version 0.94_12 [message #37 is a reply to message #35] Fri, 14 November 2003 16:06 Go to previous message
Matthias Hengartner is currently offline  Matthias Hengartner
Messages: 57
Registered: August 2003
Member
Hallo,

> - Bezieht sich das Attribut "pos" auf die externe Kilometrierung (ist es
> also ein Wert zwischen "kmBegin" und "kmEnd") oder ist es ein Wert relativ
> zum Gleisanfang? Früher, in der Version 0.93, gab es ja intPos und
> extPos... da war die Namensgebung eindeutiger (obwohl dadurch Werte
> redundant abgelegt werden konnten, was mich immer skeptisch macht. Daher
> begrüße ich die Darstellung in der Version 0.94_12)

"pos" bezieht sich auf die externe Kilometrierung. Dies wurde zwar nirgendwo
explizit erwähnt, aber es wurde in der Beispieldatei so praktiziert...

Wie Du vielleicht gesehen hast, kann die Kilometrierung nach einem der
beiden Muster (1. km: {dddd}d.d{dddd} und 2. km + m: {dddd}d.d +
{ddd}dd{.dd}) eingegeben werden. Dies wurde - soweit ich weiss - so
modelliert, dass die Position trotz Kilometrierungssprüngen eindeutig
bleibt. Bei der letzten railML-Tagung kam jedoch die Idee auf, dass
stattdessen ein zweites, optionales Attribut hinzukommt. Ich kann Dir jedoch
noch nichts genaueres dazu sagen.

Allgemein gibt es viele Elemente und Attribute, deren Gebrauch noch genau
spezifiziert werden muss.


> - Wie kombiniere ich mehrere "track"-Elemente (also den Inhalt von
> "tracks") zu einer "line"? Ist da alleine die Kilometrierung
> ausschlaggebend? Oder schlicht die Reihenfolge in der XML-Datei? Oder soll
> das aus den IDs abgeleitet werden? Noch provozierender gefragt: Wozu
> brauche ich überhaupt mehrere "track"-Elemente?

Eine <line> ist ja eigentlich nur eine Gruppierung von <track>-Elementen.
Man kann sich z.B. vorstellen, dass man eine einfache <line> von Station A
nach Station B hat. Dies sagt noch nichts über die eigentliche
Gleistopologie aus. Wenn die Strecke z.B. zweispurig ist, dann hat die Linie
zwei <track>-Elemente (diese haben dann typischerweise dieselben
Kilometrierungswerte beim Gleisanfang und -ende. Wenn auf der Strecke noch
eine Kurze Ausweichstrecke vorkommt, dann kommt noch ein drittes
<track>-Element hinzu mit der entsprechenden Kilometrierung. Die Gruppierung
von <tracks> zu einer <line> ist also (zumindest bisher) für mehrere
PARALLELE Gleise gedacht. Durch das <switch>-Element können Gleisübergänge
und Weichen modelliert werden.
Gerade hier liegt meiner Meinung nach noch ein wesentlicher Schwachpunkt des
aktuellen Schemas: Die einzige Möglichkeit, um Tracks (und somit auch Lines)
miteinander zu verbinden, ist eben dieses <switch>-Element. Das ist gut für
Gleisübergänge und ok für abzweigende Gleise, aber ziemlich unschön für
Verknüpfungen zweier Tracks (oder auch Lines) zu einem durchgehenden Gleis
(bzw. Linie).
Dieses Thema steht weit oben auf der ToDo-Liste meiner Tätigkeiten in der
kommenden Zeit. Es wird sich also diesbezüglich bald etwas tun und ich werde
einen neuen Vorschlag für das Schema zur Diskussion stellen. Vorerst hoffe
ich, dass ich Deine Frage halbwegs zufriedenstellend beantwortet habe?!

> Außerdem stand noch meine alte Frage im Raum, wie man Balisenpositionen am
> besten ablegen kann. Ich kann vorwegnehmen, dass Matthias und Daniel
> Hürlimann sich darüber nochmal Gedanken machen wollen.

Du hast recht, Elemente wie z.B. Balisen sind bisher nicht integriert (man
korrigiere mich, wenn ich diesbzgl. falsch liege!). Ein
<trainProtectionChange>-Element ist definiert ja nur die Art der
Zugssicherung und steht nicht für eine Zugssicherungs-Komponente.
Eine mögliche Variante wäre sicherlich, Balisen als weiteren Signal-Typ zu
modellieren. Würden da vielleicht weitere Attribute notwendig?
Du könntest ja die Ideen (auch betreffend den anderen
Zugssicherungs-Elementen), die Du mir im Mail geschildert hast, auch noch
hier anbringen oder sogar bereits in das Schema integrieren und dieses dann
zur Diskussion stellen (natürlich in der Hoffnung, dass daraus auch wirklich
eine Diskussion entsteht).


Grüsse aus Zürich
Matthias Hengartner
Previous Topic: infrastructure v094_12 - suggestion
Next Topic: Modified V94_12
Goto Forum:
  


Current Time: Thu Mar 28 20:52:10 CET 2024