Ergänzungen zu den XML-Dateiformaten: Unterschied zwischen den Versionen
(→Beispiel: +Beispiele (ja, mir ist langweilig.)) |
|||
(16 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 3: | Zeile 3: | ||
== Allgemeines == | == Allgemeines == | ||
* Bei | * Bei Attributen existiert für jeden Typ ein Standardwert, der verwendet wird, wenn das Attribut nicht vorhanden oder leer (Attribut="") ist. Es folgt daraus, dass das Attribut auch beim Schreiben weggelassen werden kann, wenn sein Wert dem Standardwert entspricht. Zusi macht das konsequent so. [http://forum.zusi.de/viewtopic.php?p=233206#p233206 Quelle.] Der Standardwert ist | ||
* | ** bei Ganzzahlen (integer, integer 64 bit, integer enum, bool) der Wert <code>0</code>. | ||
** bei Gleitkommazahlen (single) der Wert <code>0.0</code>. | |||
** bei Zeichenketten (string) die leere Zeichenkette. | |||
** bei Farben (D3DColor) die Farbe <code>R=G=B=A=0</code>. | |||
** bei Datums-/Zeitangaben (date,time) der <code>30. Dezember 1899, 00:00:00</code>. | |||
* Dateipfade (<code><Datei Dateiname="..."></code> sind entweder | |||
** Pfade relativ zum Zusi-Datenverzeichnis (<code>RollingStock\Deutschland\Lok.ls3</code>), wobei ein führender Backslash erlaubt ist und ignoriert wird, oder | |||
** wenn sie keinen Backslash enthalten, Dateien im selben Verzeichnis wie die Datei, in der der Pfad steht. | |||
:Insbesondere können Dateien, die auf einem anderen Laufwerk als das Zusi-Datenverzeichnis liegen, nicht referenziert werden. | |||
* Programmseitig generierte XML-Dateien, die UTF-8-kodiert sind, sollten eine Byte Order Mark (<code>0xEF,0xBB,0xBF</code>) am Anfang enthalten, damit Texteditoren sie zuverlässig als UTF-8 erkennen, siehe [[UTF-8 Byte Order Mark setzen]]. | * Programmseitig generierte XML-Dateien, die UTF-8-kodiert sind, sollten eine Byte Order Mark (<code>0xEF,0xBB,0xBF</code>) am Anfang enthalten, damit Texteditoren sie zuverlässig als UTF-8 erkennen, siehe [[UTF-8 Byte Order Mark setzen]]. | ||
* Bei Gleitkommazahlen werden sowohl Punkt als auch Komma als Dezimaltrenner betrachtet. In alten Dateien findet sich im Knoten <code>Info</code> das Attribut <code>DecSep</code>, das aber anscheinend ignoriert wird. | |||
== Einheiten == | |||
Einige Werte werden in der XML-Datei anders gespeichert, als sie in der Benutzeroberfläche von Zusi angezeigt werden. | |||
* Geschwindigkeiten: in der XML-Datei in m/s gespeichert, in der Programmoberfläche (derzeit) in km/h angezeigt. Ausnahme sind die <code>Wert</code>-Attribute in <code>Ereignis</code>-Knoten der Ereignisse "Indusi 1000 Hz" und "Indusi 2000 Hz". Diese werden in der XML-Datei in km/h gespeichert. | |||
* Winkel: in der XML-Datei im Bogenmaß gespeichert, in der Programmoberfläche in Grad angezeigt. | |||
* Krümmung von Streckenelementen: in der XML-Datei in 1/m gespeichert, im 3D-Editor in 1/km angezeigt. | |||
* Überhöhung von Streckenelementen: in der XML-Datei als Winkel im Bogenmaß gespeichert, im Gleisplaneditor und 3D-Editor in Grad und in mm (gemäß eingestelltem Oberbau) angezeigt. | |||
== Gleisplan (.st2) == | |||
Das Format ist sehr redundant, daher braucht man einige Werte nicht eintragen; sie werden vom Gleisplaneditor ignoriert und selbst berechnet: | |||
* <code><Gerade></code>: Attribut <code>W</code> beider <code><PunktWinkel></code>-Elemente | |||
* <code><Kreisbogen></code>: Die beiden <code><PunktWinkel></code>-Elemente können leer bleiben (aber nicht weggelassen werden). Nur das dritte Element (<code><Punkt></code>, der Kreismittelpunkt) ist relevant. | |||
* <code><Klothoide></code>: Das zweite <code><PunktWinkel></code>-Element kann leer bleiben (aber nicht weggelassen werden). Nur das erste Element ist relevant. Es gibt immer den Anfangspunkt der gesamten Klothoide, also den Punkt mit Krümmung 0, an. Bei Klothoidensektoren (<code>KrAnf</code> != 0) entspricht das einem fiktiven Anfangspunkt, der außerhalb des Klothoidensektors liegt. | |||
* <code><Weiche></code>: Attribut <code>BiegeWinkel</code> der <code><Biegung></code>-Elemente | |||
== Strecke (.st3) == | == Strecke (.st3) == | ||
Zeile 17: | Zeile 42: | ||
Bei <code>NachNorm</code> und <code>NachGegen</code> handelt es sich um die Nummer eines ''Streckenelements'' im selben Modul. | Bei <code>NachNorm</code> und <code>NachGegen</code> handelt es sich um die Nummer eines ''Streckenelements'' im selben Modul. | ||
Bei <code>NachNormModul</code> und <code>NachGegenModul</code> handelt es sich um die Nummer eines ''Referenzpunkts'' im durch den <code>Datei</code>-Kindknoten angegebenen Modul. | Bei <code>NachNormModul</code> und <code>NachGegenModul</code> handelt es sich um die Nummer eines ''Referenzpunkts'' im durch den <code>Datei</code>-Kindknoten angegebenen Modul. Der Referenzpunkt ist vom Typ "Modulgrenze" und zeigt in Richtung der Modulgrenze. Existiert so ein Referenzpunkt nicht, erscheint beim Verknüpfen des Streckennetzes die Fehlermeldung ''Auf Element-Nr. %d folgt Nr. %d in Modul "%s", ist dort aber nicht als Schnittstelle definiert (Verknüpfung nicht hergestellt)'' | ||
=== Reihenfolge <code>NachNorm</code> und <code>NachNormModul</code> bzw. <code>NachGegen</code> und <code>NachGegenModul</code> === | |||
Der 3D-Editor schreibt die Knoten immer in der festen Reihenfolge: | |||
# alle <code>NachNorm</code>-Knoten | |||
# alle <code>NachGegen</code>-Knoten | |||
# alle <code>NachNormModul</code>-Knoten | |||
# alle <code>NachGegenModul</code>-Knoten | |||
Ein Mischen von <code>NachXXX</code> und <code>NachXXXModul</code> im selben Streckenelement ist also nicht möglich. Dass in derselben Richtung sowohl Nachfolger im selben als auch in anderen Modulen vorhanden sind, ist ohnehin ein theoretischer Fall, der keine sinnvolle Anwendung hat. Hat ein Element in einer Richtung Nachfolger im selben Modul, so ignoriert die Fahrstraßenerzeugung des 3D-Editors Nachfolger in anderen Modulen bei der Fahrstraßenerzeugung. | |||
=== <code>Anschluss</code>-Attribut des <code>StrElement</code>-Knotens === | === <code>Anschluss</code>-Attribut des <code>StrElement</code>-Knotens === | ||
Dieses Attribut kodiert auf effiziente Weise die Richtung der Nachfolgerelemente ''des eigenen Moduls''. | Dieses Attribut kodiert auf effiziente Weise die Richtung der Nachfolgerelemente ''des eigenen Moduls''. (Nachfolgerelemente in einem anderen Modul sind über einen Referenzpunkt angegeben (s.o.), der auch eine Richtungsangabe enthält -- zu beachten ist, dass diese in Richtung der Modulschnittstelle zeigt). | ||
Es handelt sich um eine 16-Bit-Zahl. In den unteren 8 Bits ist die Richtung der (maximal 8) Nachfolgerelemente in Normrichtung (blau) gespeichert, beginnend mit dem niedrigsten Bit für den ersten Nachfolger. In den oberen 8 Bits ist die Richtung der (maximal 8) Nachfolgerelemente in Gegenrichtung (grün) gespeichert. Ein Bit 1 an der entsprechenden Stelle bedeutet, dass der Nachfolger in ''Gegen''richtung liegt. | Es handelt sich um eine 16-Bit-Zahl. In den unteren 8 Bits ist die Richtung der (maximal 8) Nachfolgerelemente in Normrichtung (blau) gespeichert, beginnend mit dem niedrigsten Bit für den ersten Nachfolger. In den oberen 8 Bits ist die Richtung der (maximal 8) Nachfolgerelemente in Gegenrichtung (grün) gespeichert. Ein Bit 1 an der entsprechenden Stelle bedeutet, dass der Nachfolger in ''Gegen''richtung liegt. | ||
Zeile 78: | Zeile 113: | ||
Für Farbangaben gibt es aus historischen Gründen zwei Formate. | Für Farbangaben gibt es aus historischen Gründen zwei Formate. | ||
* | * ABGR: Die Farbe wird als String "0AABBGGRR" kodiert. | ||
* | * ARGB: Die Farbe wird als String "AARRGGBB" kodiert. | ||
RR/GG/BB/AA steht für die zweistellige Hexadezimalrepräsentation des Rot-/Grün-/Blau-/Alpha-Farbanteils als Zahl zwischen 0 und 255. | RR/GG/BB/AA steht für die zweistellige Hexadezimalrepräsentation des Rot-/Grün-/Blau-/Alpha-Farbanteils als Zahl zwischen 0 und 255. | ||
Neu geschriebene Dateien sollen das | Neu geschriebene Dateien sollen das ARGB-Format verwenden. Das ABGR-Format begegnet einem beim Parsen bestehender Dateien des Öfteren. Zur Unterscheidung verwenden die beiden Formate unterschiedliche Attributnamen: | ||
{| class="wikitable" | {| class="wikitable" | ||
Zeile 91: | Zeile 126: | ||
! Emit (Nachtfarbe) | ! Emit (Nachtfarbe) | ||
|- | |- | ||
| | | ABGR | ||
| C | | C | ||
| CA | | CA | ||
| E | | E | ||
|- | |- | ||
| | | ARGB | ||
| Cd | | Cd | ||
| Ca | | Ca |
Aktuelle Version vom 6. Juni 2024, 08:21 Uhr
Hier werden Hinweise zu Stellen in den XML-Dateiformaten gesammelt, die nicht selbsterklärend sind.
Allgemeines
- Bei Attributen existiert für jeden Typ ein Standardwert, der verwendet wird, wenn das Attribut nicht vorhanden oder leer (Attribut="") ist. Es folgt daraus, dass das Attribut auch beim Schreiben weggelassen werden kann, wenn sein Wert dem Standardwert entspricht. Zusi macht das konsequent so. Quelle. Der Standardwert ist
- bei Ganzzahlen (integer, integer 64 bit, integer enum, bool) der Wert
0
. - bei Gleitkommazahlen (single) der Wert
0.0
. - bei Zeichenketten (string) die leere Zeichenkette.
- bei Farben (D3DColor) die Farbe
R=G=B=A=0
. - bei Datums-/Zeitangaben (date,time) der
30. Dezember 1899, 00:00:00
.
- bei Ganzzahlen (integer, integer 64 bit, integer enum, bool) der Wert
- Dateipfade (
<Datei Dateiname="...">
sind entweder- Pfade relativ zum Zusi-Datenverzeichnis (
RollingStock\Deutschland\Lok.ls3
), wobei ein führender Backslash erlaubt ist und ignoriert wird, oder - wenn sie keinen Backslash enthalten, Dateien im selben Verzeichnis wie die Datei, in der der Pfad steht.
- Pfade relativ zum Zusi-Datenverzeichnis (
- Insbesondere können Dateien, die auf einem anderen Laufwerk als das Zusi-Datenverzeichnis liegen, nicht referenziert werden.
- Programmseitig generierte XML-Dateien, die UTF-8-kodiert sind, sollten eine Byte Order Mark (
0xEF,0xBB,0xBF
) am Anfang enthalten, damit Texteditoren sie zuverlässig als UTF-8 erkennen, siehe UTF-8 Byte Order Mark setzen. - Bei Gleitkommazahlen werden sowohl Punkt als auch Komma als Dezimaltrenner betrachtet. In alten Dateien findet sich im Knoten
Info
das AttributDecSep
, das aber anscheinend ignoriert wird.
Einheiten
Einige Werte werden in der XML-Datei anders gespeichert, als sie in der Benutzeroberfläche von Zusi angezeigt werden.
- Geschwindigkeiten: in der XML-Datei in m/s gespeichert, in der Programmoberfläche (derzeit) in km/h angezeigt. Ausnahme sind die
Wert
-Attribute inEreignis
-Knoten der Ereignisse "Indusi 1000 Hz" und "Indusi 2000 Hz". Diese werden in der XML-Datei in km/h gespeichert. - Winkel: in der XML-Datei im Bogenmaß gespeichert, in der Programmoberfläche in Grad angezeigt.
- Krümmung von Streckenelementen: in der XML-Datei in 1/m gespeichert, im 3D-Editor in 1/km angezeigt.
- Überhöhung von Streckenelementen: in der XML-Datei als Winkel im Bogenmaß gespeichert, im Gleisplaneditor und 3D-Editor in Grad und in mm (gemäß eingestelltem Oberbau) angezeigt.
Gleisplan (.st2)
Das Format ist sehr redundant, daher braucht man einige Werte nicht eintragen; sie werden vom Gleisplaneditor ignoriert und selbst berechnet:
<Gerade>
: AttributW
beider<PunktWinkel>
-Elemente<Kreisbogen>
: Die beiden<PunktWinkel>
-Elemente können leer bleiben (aber nicht weggelassen werden). Nur das dritte Element (<Punkt>
, der Kreismittelpunkt) ist relevant.<Klothoide>
: Das zweite<PunktWinkel>
-Element kann leer bleiben (aber nicht weggelassen werden). Nur das erste Element ist relevant. Es gibt immer den Anfangspunkt der gesamten Klothoide, also den Punkt mit Krümmung 0, an. Bei Klothoidensektoren (KrAnf
!= 0) entspricht das einem fiktiven Anfangspunkt, der außerhalb des Klothoidensektors liegt.<Weiche>
: AttributBiegeWinkel
der<Biegung>
-Elemente
Strecke (.st3)
Zuordnung Norm/Gegen ↔ blau/grün
In der Programmoberfläche werden ausschließlich die Bezeichnungen "blaue und grüne Richtung" verwendet. Diese entsprechen Norm- bzw. Gegenrichtung im Dateiformat. Merkhilfe: grün = Gegenrichtung.
Nr
-Attribut NachNorm[Modul]
und NachGegen[Modul]
-Knoten im StrElement
-Knoten
Bei NachNorm
und NachGegen
handelt es sich um die Nummer eines Streckenelements im selben Modul.
Bei NachNormModul
und NachGegenModul
handelt es sich um die Nummer eines Referenzpunkts im durch den Datei
-Kindknoten angegebenen Modul. Der Referenzpunkt ist vom Typ "Modulgrenze" und zeigt in Richtung der Modulgrenze. Existiert so ein Referenzpunkt nicht, erscheint beim Verknüpfen des Streckennetzes die Fehlermeldung Auf Element-Nr. %d folgt Nr. %d in Modul "%s", ist dort aber nicht als Schnittstelle definiert (Verknüpfung nicht hergestellt)
Reihenfolge NachNorm
und NachNormModul
bzw. NachGegen
und NachGegenModul
Der 3D-Editor schreibt die Knoten immer in der festen Reihenfolge:
- alle
NachNorm
-Knoten - alle
NachGegen
-Knoten - alle
NachNormModul
-Knoten - alle
NachGegenModul
-Knoten
Ein Mischen von NachXXX
und NachXXXModul
im selben Streckenelement ist also nicht möglich. Dass in derselben Richtung sowohl Nachfolger im selben als auch in anderen Modulen vorhanden sind, ist ohnehin ein theoretischer Fall, der keine sinnvolle Anwendung hat. Hat ein Element in einer Richtung Nachfolger im selben Modul, so ignoriert die Fahrstraßenerzeugung des 3D-Editors Nachfolger in anderen Modulen bei der Fahrstraßenerzeugung.
Anschluss
-Attribut des StrElement
-Knotens
Dieses Attribut kodiert auf effiziente Weise die Richtung der Nachfolgerelemente des eigenen Moduls. (Nachfolgerelemente in einem anderen Modul sind über einen Referenzpunkt angegeben (s.o.), der auch eine Richtungsangabe enthält -- zu beachten ist, dass diese in Richtung der Modulschnittstelle zeigt).
Es handelt sich um eine 16-Bit-Zahl. In den unteren 8 Bits ist die Richtung der (maximal 8) Nachfolgerelemente in Normrichtung (blau) gespeichert, beginnend mit dem niedrigsten Bit für den ersten Nachfolger. In den oberen 8 Bits ist die Richtung der (maximal 8) Nachfolgerelemente in Gegenrichtung (grün) gespeichert. Ein Bit 1 an der entsprechenden Stelle bedeutet, dass der Nachfolger in Gegenrichtung liegt.
Beispiel
Situation (grünes Ende ==Nr==> blaues Ende )
|
Nachfolger von (2, NORM)
|
Nachfolger von (2, GEGEN)
|
Anschluss-Wert von Element Nr. 2 |
---|---|---|---|
==1==> ==2==> ==3==>
|
(3, NORM)
|
(1, GEGEN)
|
256 = 28 |
==1==> ==2==> <==3==
|
(3, GEGEN)
|
(1, GEGEN)
|
257 = 28 + 20 |
<==1== ==2==> ==3==>
|
(3, NORM)
|
(1, NORM)
|
0 |
<==1== ==2==> <==3==
|
(3, GEGEN)
|
(1, NORM)
|
1 = 20 |
Pseudocode
Um für ein Element-Richtungs-Tupel (Element, Richtung)
die Richtung des i
-ten Nachfolgers zu bestimmen, wobei i
von 0 indiziert ist:
anschluss_shift := i + (if richtung == GEGEN then 8 else 0) nachfolger_richtung := if (anschluss >> anschluss_shift) & 1 == 0 then NORM else GEGEN
FahrstrWeichenlage
-Attribut des FahrstrWeiche
-Knotens
Dieses Attribut ist, anders als die Nachfolger von Streckenelementen, 1-indiziert.
Speicherreihenfolge der Signalmatrix-Einträge
Die Signalmatrizen sind zeilenweise gespeichert. Die Anzahl Spalten ergibt sich aus der Anzahl VsigBegriff
-Knoten, die Anzahl Zeilen aus der Anzahl HsigBegriff
-Knoten. Wenn matrix
eine Liste der MatrixEintrag
-Knoten ist, dann ist matrix[zeile * anz_spalten + spalte]
der Matrixeintrag für die angegebene Zeile und Spalte (jeweils 0-indiziert).
Landschaft (.ls3)
Farbwerte bei Subset
-Knoten
Für Farbangaben gibt es aus historischen Gründen zwei Formate.
- ABGR: Die Farbe wird als String "0AABBGGRR" kodiert.
- ARGB: Die Farbe wird als String "AARRGGBB" kodiert.
RR/GG/BB/AA steht für die zweistellige Hexadezimalrepräsentation des Rot-/Grün-/Blau-/Alpha-Farbanteils als Zahl zwischen 0 und 255.
Neu geschriebene Dateien sollen das ARGB-Format verwenden. Das ABGR-Format begegnet einem beim Parsen bestehender Dateien des Öfteren. Zur Unterscheidung verwenden die beiden Formate unterschiedliche Attributnamen:
Format | Diffuse | Ambient | Emit (Nachtfarbe) |
---|---|---|---|
ABGR | C | CA | E |
ARGB | Cd | Ca | Ce |