Home » railML newsgroups » railml.timetable » timetable-Schema 0.93
| timetable-Schema 0.93 [message #590] |
Wed, 29 May 2002 17:21  |
Raik Hoffmann
Messages: 12
Registered: May 2002
|
Junior Member |
|
|
Unter railml.org ist die neue Version (v0.93) des timetable-Schemas
abgelegt.
Als Diskussionspunkte sehe ich die Verknüpfung mit dem Infrastruktur-Schema,
und die Angabe der IST-Auswertung der Fahrpläne (-> statistics)
Die Elemente der Infrastruktur werden momentan in den Fahrplaneinträgen (
\train\timetable\entry\ ) als ID referenziert. Die Bezeichnung ID ist
eindeutig, da es im Schema kein weiteres Attribut "ID" gibt. Man könnte das
Attribut auch entryID nennen, angesichts der sehr häufigen Verwendung würden
die Dateien aber wesentlich größer werden.
Bei der IST-Auswertung des Fahrplanes wäre zu diskutieren, inwieweit man
diese in das STATISTICS-Schema verlagert.
Ich freue mich auf Anmerkungen und Kritik.
Viele Grüße,
Raik Hoffmann
|
|
|
|
|
|
| Re: timetable-Schema 0.93 [message #592 is a reply to message #591] |
Mon, 03 June 2002 09:53  |
huerlimann
Messages: 11
Registered: October 2005
|
Junior Member |
|
|
Danke fuer Deine Aenderungen. Ich schlage fuer die Verwaltung von
verschiedenen Fahrplaenen fuer den gleichen Zug (z.B. Sollfahrplan,
Istfahrplan an best. Datum, ...) vor gemaess der Idee am Startup-Meeting
pro train mehrere timetable zuzulassen. Mit Attributen (z.B type fuer die
Art von Eintraegen, source fuer die Datenherkunft und date fuer das
entsprechende Datum) wie sie aktuell im statistic-Tag drin sind koennte
man die einzelnen timetables pro Zug unterscheidbar machen.
Was die Benennung der Fahrplaneintraege betrifft, bin ich mit ID noch
nicht so gluecklich. entryID ist auch nicht gut, da man dies als
Schluessel auf irgendeine entry verstehen koennte, was es aber nicht
ist. Es ist ein Schluessel auf eine Betriebsstelle oder einen Ort
(Kilometrierung). Daher waere vielleicht locationID, locID, stationID oder
so was aehnliches zu verwenden, welches dann auch in den
Stationsbeschreibungen wieder als Schluessel fuer eine Station
auftauchen muss.
Was ich auch noch gut faende, ist wenn man pro entry mehrere trackIDs
angeben koennte (z.B. nach Prioritaeten alle in der Station benutzbaren).
Das im Beispielfile timetable.xml verwendete Vermischen von Zeitwerten
und Typ des Fahrplaneintrages (z.B. arrival = "pass") wuerde ich
vermeiden und wuerde dies in einen speziellen Type des
Fahrplaneintrages reinnehmen (z.B. begin, end, stop, pass) .
|
|
|
|
| Re: timetable-Schema 0.93 [message #593 is a reply to message #592] |
Fri, 21 June 2002 15:23 |
Raik Hoffmann
Messages: 12
Registered: May 2002
|
Junior Member |
|
|
Hallo,
ich habe fuer die Unterscheidung der train's die Attribute type, source und
date ergaenzt.
type ist ein string-typ und soll fuer die Unterscheidung nach Art von
Eintraegen stehen.
source ist ebenfalls string-typ und steht fuer die Datenherkunft.
date ist vom date-Datentyp und steht fuer das Datum des Zuglaufes.
Was fuer moegliche Auspraegungen waeren bei type und source denkbar?
Eventuell ist es besser, die nachgelagerte IST-Auswertung eines Zuglaufes
komplett in das STATISTICS-Schema zu uebernehmen?
Zu der Benennung der ID bei entry.
Diese ID kann nicht nur auf Bahnhoefe verweisen, sondern referenziert -
abstrakt gesprochen - einen "Fahrzeitmesspunkt". An diesem Fahrzeitmesspunkt
kann sich (quasi zufaellig) auch ein Bahnhof, ein Signal, Weiche, ...
befinden. Im einfachsten Fall ist dies aber einfach nur ein Punkt auf der
freien Strecke.
> Was ich auch noch gut faende, ist wenn man pro entry mehrere trackIDs
> angeben koennte (z.B. nach Prioritaeten alle in der Station benutzbaren).
Gehoert das nicht eher in ein Bahnhofsfahrordnungs-Schema oder
Betriebsmanagement-Schema?
Der Zug sucht sich doch nicht (aktiv) einen Weg anhand seiner mitgegebenen
Informationen durch den Bahnhof, sondern wird (passiv) auf einem
vorgegebenen Weg durch den Bahnhof gefuehrt.
Allerdings kann man im header eines trains eine "stationTrack"-list
referenzieren. Diese Liste beinhaltet ja die zu befahrenden Gleise in einem
Bahnhof. In dieser koennte man auch Prioritaeten oder Regeln fuer die zu
befahrenden Gleise angeben...
> Das im Beispielfile timetable.xml verwendete Vermischen von Zeitwerten
> und Typ des Fahrplaneintrages (z.B. arrival = "pass") wuerde ich
> vermeiden und wuerde dies in einen speziellen Type des
> Fahrplaneintrages reinnehmen (z.B. begin, end, stop, pass) .
Ja, ich bin mit der existierenden Loesung auch nicht zufrieden.
Ich hatte das auf dem Auftakttreffen schon versucht anzusprechen.
Das bisherige System im Schema funktioniert wie in der Tabelle unter
http://www.railml.org/table_1.gif dargestellt.
Die Attribute arrival und departure sind dabei required.
Es gibt natuerlich die Moeglichkeit, fuer jedes Szenario spezielle Attribute
einzufuehren, oder nur Zeitwerte in den Attributen zuzulassen. Ich habe aber
festgestellt, dass sich dies nur mit erhoehtem Aufwand implementieren
laesst. Man muss also jedesmal auf eine z.B. Durchfahrt testen, indem man
die Werte in arrival und departure auf Gleichheit prueft.
Die Attribute optional zu machen und damit weitere optionale Attribute
begin, end und pass einzufuehren blaeht die verarbeitende Routine auf. Da
diese aber *sehr* oft durchlaufen werden muss, wuerde ich dabei auf kurze
Rechenzeit optimieren, also so wie in der Tabelle...
Bin mit der Loesung aber auch noch nicht ganz zufrieden und freue mich auf
weitere Vorschlaege!
Viele Gruesse,
Raik Hoffmann
|
|
|
|
| Re: timetable-Schema 0.93 [message #594 is a reply to message #593] |
Tue, 02 July 2002 11:12 |
huerlimann
Messages: 11
Registered: October 2005
|
Junior Member |
|
|
Hallo zusammen
Besten Dank an Raik für die Ergänzung des Schemas mit den bei den Trains
angesiedelten Attributen type, source und date.
Was mir aufgefallen ist, ist das beim aktuellen Format zwei nicht
gleichbedeutende
Elemente (Tags) timetable gibt, einmal unter railml und einmal unter
train. Dies sollte
natürlich verhindert werden. Ich schlage vor, den unter train angesiedelte
timetable
traintimetable zu nennen und die obengenannte Attribute type, source und
date unter
traintimetable ansiedelt. D.h. dass es pro Zugnummer einen Train geben
wuerde mit
einem bis mehreren traintimetables.
Fuer die Verwendung der neuen Attribute mache ich folgenden Vorschlag:
type: planned, actual oder calculated (je nachdem ob die vorliegenden
Daten
Sollvorgaben, Istdaten oder Resultate von Berechnungen sind)
source: Herkunft der Daten. Dies soll ein freier String sein welcher das
System der
Datenherkunft beschreibt (z.B. FBS, Viriato, OpenTrack, SBB-KVZ, SBB-SURF,
DB-
RUT, ...). Beim Import mehrerer Fahrplänen pro Zug (z.B. Solldaten aus
FBS und
berechnete Ist-Daten aus OpenTrack) könnte der User dann auswählen, welche
Daten
er laden will, wobei der source-String zusammen mit dem type und dem date
diese
Datenbestände unterscheiden würde.
Nochmals zur ID bei den entry-Elementen. Die heute verwendete ID
bezeichnet einen
Ort der Infrastruktur, für welchen der oder die angegebenen Zeitwerte
gelten. Das kann
ein Signal, eine Betriebsstelle etc. sein. Aber es handelt sich immer um
eine
identifizierbare Position (Location) irgendwo im Gleisnetz. Daher schlage
ich nochmals
vor, diesen Sachverhalt im Attributnamen zu verankern. locID oder
locationID heisst,
dass es in der Infrasturkturbeschreibung ein Element geben muss (z.B.
Station, Signal),
welches diese locationID ebenfalls als Attribut trägt, d.h. die Zeit kann
dann einem
realen Objekt der Anlage zugeordnet werden.
Zu begin, end, pass, stop, arrival und departure. Ich bin immer noch fuer
die Teilung der
beiden Informationen Zeit und Typ des Eintrages, wobei auch die Zeiten
optional sein
muessen, d.h. wir muessen keine Ankunftszeit definieren, wenn dies nicht
nötig ist. Es
muss z.B. möglich sein für einen Statinonshalt nur die minimale Haltezeit
anzugeben
ohne einen effektiven Zeitwert. Ich denke nicht, dass die Importfunktion
damit
komplexer wird. Man hat dann zwei verschiedene Datentypen zu handeln,
einen Typ
und eine Zeit. Fehlt eine Angabe, so muss man mit geschickten
Defaultwerten arbeiten.
Typischerweise muss man eben dann für das Feststellen einer Durchfahrt
nicht arrival
und departure auf Gleichheit prüfen sondern das Attribut type='pass' sagt
dies explizit.
Fehlt dann z.B. sowohl eine stop wie eine pass Information kann immer noch
geschaut
werden, ob sowohl arrival wie departure definiert sind, um diese dann zu
vergleichen.
Zu den verwendbaren Stationsgleisen (trackID): Es wäre halt schön, wenn
man in den
Planungsdaten angeben könnte, welche Gleise ein Zug befahren darf (1.
Priorität, 2.
Priorität, ...) und dann in den Istdaten sehen könnte, welches Gleis der
Zug effektiv
befahren hat. Würde man einen RailML-Timetable z.B. innerhalb eines
Fahrplanentwurfstools verwenden könnte das Tool selbständig prüfen, ob für
die
gewünschte Solllage des Zuges noch eines der angegebenen Stationsgleise
verfügbar
ist.
Ich hoffe, dass Ihr diese Vorschläge analysiert und wir für RailML eine
gute Lösung
bzw. Integration der beschriebenen Sachverhalte finden.
Grüsse aus Zürich
Dani Hürlimann
|
|
|
|
| Re: timetable-Schema 0.93 [message #595 is a reply to message #594] |
Mon, 22 July 2002 20:14 |
Raik Hoffmann
Messages: 12
Registered: May 2002
|
Junior Member |
|
|
Hallo,
> Was mir aufgefallen ist, ist das beim aktuellen Format zwei nicht
> gleichbedeutende
> Elemente (Tags) timetable gibt, einmal unter railml und einmal unter
> train. Dies sollte natürlich verhindert werden.
Oh ja, stimmt.
Ich habe das abgeändert.
Unter "Train" gibt es jetzt das Element "Timetableentries".
> Nochmals zur ID bei den entry-Elementen. Die heute verwendete ID
> bezeichnet einen
> Ort der Infrastruktur, für welchen der oder die angegebenen Zeitwerte
> gelten. Das kann
> ein Signal, eine Betriebsstelle etc. sein. Aber es handelt sich immer um
> eine
> identifizierbare Position irgendwo im Gleisnetz. Daher schlage
> ich nochmals vor, diesen Sachverhalt im Attributnamen zu verankern.
Ok, habe die Referenzierung der Position in "posID" umbenannt.
> Zu begin, end, pass, stop, arrival und departure. Ich bin immer noch fuer
> die Teilung der
> beiden Informationen Zeit und Typ des Eintrages, wobei auch die Zeiten
> optional sein
> muessen, d.h. wir muessen keine Ankunftszeit definieren, wenn dies nicht
> nötig ist. Es
> muss z.B. möglich sein für einen Statinonshalt nur die minimale Haltezeit
> anzugeben
> ohne einen effektiven Zeitwert.
Hm, ein Fahrplan ist aber immer das Ergebnis eines Berechnungsverfahrens,
und damit ist die konkrete Zeit für jeden Punkt der Strecke bekannt.
> Zu den verwendbaren Stationsgleisen (trackID): Es wäre halt schön, wenn
> man in den
> Planungsdaten angeben könnte, welche Gleise ein Zug befahren darf
ja, das kann man so angeben.
Im Header jedes Zuges ist dafür eine Referenz (stationTrackID) vorgesehen.
Damit kann man quasi eine Bahnhofsfahrordung definieren. Unterschieden
werden kann da entweder grob in Zuggattungen, oder konkret für einen
speziellen Zug.
Viele Grüße,
Raik Hoffmann
|
|
|
|
| Re: timetable-Schema 0.93 [message #596 is a reply to message #591] |
Tue, 04 June 2002 09:52 |
dirk
Messages: 1
Registered: June 2002
|
Junior Member |
|
|
Raik Hoffmann wrote:
> Die Zeitformate wurden geändert. Zur Angabe von Zeitpunkten stehen im
> Attribute ScheduleFormat die Werte HH:MM, HH:MM:SS, HH:MM,D zur Verfügung,
> wobei HH:MM:SS der default-Wert ist.
Verstehe ich das richtig, das schreibende Programm legt beim Erzeugen der
XML-Datei das Zeitformat fest, und das lesende Programm prüft, ob das
Zeitformat gelesen werden kann (HH:MM für Bildfahrpläne im
Konstruktionsniveau = nein) und muss dann ggf. umrechnen?
Aus meiner Sicht wäre noch zu prüfen, ob man optional auch kleinere
Zeitanteile zulassen könnte, also z.B. HH:MM,dd... oder ein Äquivalent mit
Sekundenbruchteilen. Ich sehe selten, aber theoretisch (und eben doch
bereits vorgekommen) ein Problem bei dicht liegenden Elementegrenzen bei
HGV, also z.B. kurzen LZB-GFAs (können bei Hochleistungsein- und
-ausfahrten bis zu 50 m kurz sein) oder einfach nur zufällig dicht
liegenden Fahrzeitmesspunkten, die eigentlich nichts miteinander zu tun
haben (z.B. Bahnsteigmitte und Zwischensignal). Bereits bei 180 km/h
durchfährt der Zug 50 m in 1 s, der Fehler kann hier also bereits 50 %
betragen, aus meiner Sicht nicht akzeptabel.
Mal abgesehen von der internen Fahrzeitspeicherung der
Konstruktionsprogramme, die m.E. immer genauer sein dürfte als 1 s (z.B.
Besetzungszeit einer Weiche). Zugegeben, RailML kommt hier wenig in Frage,
aber wir verletzen etwas die erstrebenswerte These, dass nach einem Export
in RailML und Reimport (ins gleiche Programm) alles wieder so sein sollte
wie vorher.
Außerdem geben m.E. alle Programme dem Anwender die Möglichkeit,
Fahrzeitmesspunkte auf 1 m genau einzugeben. Wir würden ihn mit der
1-s-Grenze indirekt nötigen, dichter liegende Punkte zusammenzufassen, was
zwar mathematisch vertretbar sein wird, aber eben für den Anwender kaum
nachvollziehbar. Ich gebe zu bedenken, dass neben
Bahnsteig-/Bahnhofsmitten bzw. Halteplätzen eben auch Zwischensignale oder
LZB-Bkz. Zugfolgestellen und damit Fahrzeitmesspunkte sind, oder auf der
Strecke mal zwei Blocksignale in geringem Abstand (aber nicht unmittelbar)
Rücken an Rücken stehen können.
Bitte daher mal über eine optional feinere Zeiteinheit nachdenken.
|
|
|
|
| timetable-Schema 0.93 [message #597 is a reply to message #596] |
Mon, 10 June 2002 11:17 |
ULinder
Messages: 1
Registered: June 2002
|
Junior Member |
|
|
Ich möchte die Aussage von Dirk Bräuer unterstützen:
Zeitpunkte des Fahrplans sollten meines Erachtens mindestens das Format
HH:MM:SS,D unterstützen, wobei noch zu entscheiden ist, ob D für eine
einzelne Ziffer (0,1 s) oder für einen Dezimalwert mit beliebig vielen
Ziffern stehen soll.
Weiterhin ist zu überlegen, ob überhaupt andere (ungenauere) Formate
explizit unterstützt werden müssen, das die Dateien zu mindestens 95 % von
Programmen und zu höchstens 5 % von Menschen erstellt und gelesen werden,
d.h. es sollte kein Problem sein, dass das schreibende Programm die Zeiten
von seinem eigenen Format in das standardisierte Format umwandelt. Beim
Lesen wiederum erleichtert ein einheitliches Format die Verarbeitung.
Interessanter wäre jedoch z.B. eine (optionale) Information über die
Genauigkeit des Wertes oder über ein Zeitfenster (z.B. für Durchfahrten).
Weiterhin halte ich das Thema Zeitzonen (incl. Sommer- und Winterzeit),
und sei es nur als globale Information fuer den ganzen Fahrplan, für
wichtig.
Viele Grüße
Ulrich Linder
|
|
|
|
| Re: timetable-Schema 0.93 [message #598 is a reply to message #597] |
Fri, 21 June 2002 16:07 |
Raik Hoffmann
Messages: 12
Registered: May 2002
|
Junior Member |
|
|
Hallo,
> Weiterhin ist zu überlegen, ob überhaupt andere (ungenauere) Formate
> explizit unterstützt werden müssen, das die Dateien zu mindestens 95 % von
> Programmen und zu höchstens 5 % von Menschen erstellt und gelesen werden,
> d.h. es sollte kein Problem sein, dass das schreibende Programm die Zeiten
> von seinem eigenen Format in das standardisierte Format umwandelt. Beim
> Lesen wiederum erleichtert ein einheitliches Format die Verarbeitung.
Da stimme ich allerdings zu.
Bei einer grossen Vielfalt von Zeitformaten ist ja fuer *jedes* Zeitformat
beim importieren eine kleine Umrechnungsroutine zu schreiben. (oder man
unterstuetzt nicht alle Zeitformate - hat aber dann keinen railml-Konformen
Konverter!!)
Weniger Aufwand fuer alle beteiligen waere, *eine* Umrechnungsroutine fuers
exportieren zu schreiben und sich auf ein Zeitformat zu einigen.
(oder auch max. 2 Zeitformate: ein einfaches, beispielsweise mit
Minuten-Genauigkeit fuer Buchfahrplaene; und ein genaues, beispielsweise mit
1/100-Sekunden-Genauigkeit zur Fahrplankonstruktion)
Welche weiteren Meinungen gibt es dazu?
> Weiterhin halte ich das Thema Zeitzonen (incl. Sommer- und Winterzeit),
> und sei es nur als globale Information fuer den ganzen Fahrplan, für
> wichtig.
Dieses Thema war leider bisher noch gar nicht beruecksichtigt. Man koennte
definieren, dass die am jeweiligen Fahrzeitmesspunkt zur betreffenden Zeit
gueltige Zeit als Wert bei arrival und departure steht.
Das wuerde allerdings einen diskontinuierlichen Zeitverlauf in der XML-Datei
beim uebertritt eines Zuges in eine andere Zeitzone verursachen.
Alternativ koennte man die gueltige Zeit am Startbahnhof als Grundlage fuer
die gesamten Zeitwerte des Zuglaufes definieren. Dann muss man aber
eventuell an jedem entry auf Abweichung pruefen und ggf. umrechnen....
Welche Loesung wuerden sie vorziehen?
Viele Gruesse,
Raik Hoffmann
|
|
|
|
|
|
| Re: timetable-Schema 0.93 [message #600 is a reply to message #591] |
Tue, 06 August 2002 16:05 |
huerlimann
Messages: 11
Registered: October 2005
|
Junior Member |
|
|
Raik Hoffmann wrote:
> Die Zeitformate wurden geändert. Zur Angabe von Zeitpunkten stehen im
> Attribute ScheduleFormat die Werte HH:MM, HH:MM:SS, HH:MM,D zur Verfügung,
> wobei HH:MM:SS der default-Wert ist.
Dies scheint in V0.94 noch nicht der Fall zu sein. Das neu eingefuehrte
Format
hh:mm:ss,dd finde ich gut. Ich finde man muesste die ganze Palette
anbieten:
s
m
m:ss (nicht wie in V0.94 m:s)
hh:mm
hh:mm,d (Zehntelsminuten)
hh:mm:ss
hh:mm:ss,dd (Hundertstelsekunden)
Es sollen alle Formate dem Attribut scheduleformat und periodformat
zugewiesen
werden koennen.
Die Umwandlungsroutine, welche ein Format in ein anderes (bzw. in
dasjenige des
eigenen Tools) umwandelt ist ja wirklich einfach zu implementieren.
Gruss aus Zuerich
Dani
|
|
|
|
Goto Forum:
Current Time: Sun Nov 03 20:46:49 CET 2024
|
Members
Search
Help
Login
Home
