Talk:UC:TT:PassengerInformationAtStations: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
(Dokumentation TT-Entwicklertreffen I)
Line 5: Line 5:
# Sind die in railML2.3 neu eingeführten Attribute für Cancellation of trains/trainParts in diesem Usecase relevant?
# Sind die in railML2.3 neu eingeführten Attribute für Cancellation of trains/trainParts in diesem Usecase relevant?
# Zur Bemerkung "Übergangstyp in <rostering>" am Ende des Usecases: Was für Übergangstypen sind da gemeint, "Kopfmachen" vs. "Durchbindung ohne Kopfmachen" oder etwas anderes?
# Zur Bemerkung "Übergangstyp in <rostering>" am Ende des Usecases: Was für Übergangstypen sind da gemeint, "Kopfmachen" vs. "Durchbindung ohne Kopfmachen" oder etwas anderes?
== Diskussion bei TT-Entwicklertreffen ==
# Ein erster Meilenstein  soll definiert werden, der folgendes enthält
# Ein Zug hat noch keine Verkehrstage und es wird nur ein 'commercial' Zug benötigt.
# Zugreiseverlauf
# Angaben für "ocpTT"
  # Sollzeiten (veröffentlichte Zeiten)
  # ''Istzeiten''
  # Gleisinformation
  # Bahnhofsgleis (öffentliche Bezeichnung für Fahrgastinfo)
  # ''Betriebsstellengleis (Referenz für das Gleis in der Infrastruktur für Zuglenkung)''
  # ''Halteplatz''
  # Halt
  # stop/pass
  # ''stop on request''
  # ''Ein-/Ausstieg''
  # ''kommerzieller Halt ja/nein''
# Angaben für "sectionTT"
  # Angaben zu runTimes
  # Angaben zum Streckengleis (relevant für TMS Usecase)
  # Angaben zum Betriebsstellenfahrweg (relevant für TMS Usecase)
Diskussionspunkte für Meilenstein 1:
* Refaktorisierung Reiseverlauf
* Verwendung von Referenzen auf 'externe' IS/IL
* Anbindung IS/IL
  * für sectionTT
* Anbindung IS
  * ocp für ocpTT
  * Gleisangaben
Diskussionspunkte weitere Meilensteine:
* Refaktorisierung Verkehrstage
* Kommerzielle Züge
* Zugbehandlung: Flügeln, Kuppeln, Schwächen, Stärken, Zugtausch, Zugnummernübergang, Durchbindungen

Revision as of 11:17, 2 April 2019

Review comments by Christian Rößiger (iRFP)

  1. Werden commercial oder operational <trains> übertragen oder beides?
  2. Wird nur ein Betriebstag übertragen oder eine ganze (Fahrplan-) Periode? Wenn nur ein Betriebstag, wie wird mit Zügen umgegangen, die über Mitternacht verkehren?
  3. Enthält die Infrastruktur nur die Knoten (<ocp>s) des Netzes oder auch Kanten (<line>s bzw. <track>s)?
  4. Sind die in railML2.3 neu eingeführten Attribute für Cancellation of trains/trainParts in diesem Usecase relevant?
  5. Zur Bemerkung "Übergangstyp in <rostering>" am Ende des Usecases: Was für Übergangstypen sind da gemeint, "Kopfmachen" vs. "Durchbindung ohne Kopfmachen" oder etwas anderes?

Diskussion bei TT-Entwicklertreffen

  1. Ein erster Meilenstein soll definiert werden, der folgendes enthält
  2. Ein Zug hat noch keine Verkehrstage und es wird nur ein 'commercial' Zug benötigt.
  3. Zugreiseverlauf
# Angaben für "ocpTT"
 # Sollzeiten (veröffentlichte Zeiten)
 # Istzeiten
 # Gleisinformation
  # Bahnhofsgleis (öffentliche Bezeichnung für Fahrgastinfo)
  # Betriebsstellengleis (Referenz für das Gleis in der Infrastruktur für Zuglenkung)
  # Halteplatz
 # Halt
  # stop/pass
  # stop on request
  # Ein-/Ausstieg
  # kommerzieller Halt ja/nein
# Angaben für "sectionTT"
 # Angaben zu runTimes
 # Angaben zum Streckengleis (relevant für TMS Usecase)
 # Angaben zum Betriebsstellenfahrweg (relevant für TMS Usecase)

Diskussionspunkte für Meilenstein 1:

  • Refaktorisierung Reiseverlauf
  • Verwendung von Referenzen auf 'externe' IS/IL
  • Anbindung IS/IL
 * für sectionTT
  • Anbindung IS
 * ocp für ocpTT
 * Gleisangaben


Diskussionspunkte weitere Meilensteine:

  • Refaktorisierung Verkehrstage
  • Kommerzielle Züge
  • Zugbehandlung: Flügeln, Kuppeln, Schwächen, Stärken, Zugtausch, Zugnummernübergang, Durchbindungen