Home » railML newsgroups » railml.timetable » Protokoll Treffen 2015-0619 Berlin
Protokoll Treffen 2015-0619 Berlin [message #1304] Mon, 05 October 2015 09:55
Christian Rößiger is currently offline  Christian Rößiger
Messages: 14
Registered: March 2015
Junior Member
Hallo zusammen,

ich habe über die Inhalte unseres vergangenen Treffens in Berlin ein
paar Notizen gemacht, die ich hiermit veröffentlichen möchte. Somit kann
man später evtl. etwas besser nachvollziehen, was damals besprochen
wurde. Anregungen und Ergänzungen sind wie immer gern gesehen.

Usecases:
- Erstellung und Review der Usecase auf
http://wiki.railml.org/index.php?title=TT:UseCases soll bis zum nächsten
Treffen fortgeführt werden
- Ziel ist die Veröffentlichung der Usecases auf der railML-Homepage mit
Zuordnung der unterstützenden Programme

TAF/TAP-Vortrag von ERA
- Diskussion über Möglichkeiten der Harmonisierung von TAF/TAP und
railML, 2 Bereiche wurden identifiziert (passengerUsage und unique train
ID), Umsetzung soll in railML 2.3 erfolgen
- Beschlossen wurde, bei <passengerUsage><places> und
<passengerUsage><services> jeweils ein optionales Attribut zu ergänzen,
in dem ein TAF/TAP-Service / Platzkategorie referenziert werden kann.
Die gültigen Werte dieses Attributes werden in einer externen XML-Datei
spezifiziert (analog zu InfrastructureManagerCodes.xml). Die bisherigen
Enumerationen in railML für <places category="..."> und <service
type="..."> bleiben parallel dazu erhalten. ERA soll im Forum ein
diesbezügliches Beispiel vorstellen (Ticket #250)
- Weitere Attribute aus TAF/TAP für services/places, wie z.B.
Saisonierung oder Angabe einer verantwortlichen <organizational unit>
sollen auf railML 3 verschoben werden, da dort sowieso ein Refactoring
dieser Strukturen vorgesehen ist
- Beschlossen wurde ebenso aufgrund einer Bedarfsanmeldung, in railML
2.3 innerhalb des <train>-Elements eine zusätzliche Struktur zur
Abbildung der unique train id gemäß TAF/TAP zu implementieren. Bisherige
Möglichkeiten zur Identifikation eines Zuges bzw. <train>-Elements
bleiben erhalten

railML 2.3 allgemein
- Auftrag an iRFP zu prüfen, ob Ticket #257 umgesetzt werden soll, wenn
ja, liefert soll iRFP einen Vorschlag liefern
- Nachtragen von any-Elementen/Attributen "auf Vorrat" gemäß der
vorgestellten Regeln. iRFP liefert Liste, welche Element in <timetable>
und <infrastructure> davon betroffen sind (Ticket 268)
- Beschlossen wurde, die Dokumentation zukünftig nur noch im wiki
durchzuführen, nicht mehr zusätzlich in den annotations des Schemas
- public beta Version soll vsl. im Rahmen der railML-Konferenz im
November 2015 vorgestellt werden, das Release im Frühjahr 2016 zur
deutschsprachigen railML-Konferenz erfolgen

Nächster Termin:
- Januar 2016, Einladung erfolgt durch railML-Koordinator
- Vorschlag für TOP: Zusammentragen von Mängeln in railML 2.3 im
Hinblick auf Verbesserungsbedarf railML 3

Viele Grüße
Christian Rößiger

--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
Previous Topic: Explizite Kennzeichnung von gelöschten Zügen und Zugausfällen
Next Topic: [Request for railML3] Different station tracks in one <ocpTT> for different <operatingPeriod>s
Goto Forum:
  


Current Time: Thu May 25 18:12:51 CEST 2017