Home » railML newsgroups » railml.timetable » [railML2] Redudant attributes in <ocpTT>
[railML2] Redudant attributes in <ocpTT> [message #2712] Wed, 05 May 2021 20:45 Go to next message
Vasco Paul Kolmorgen
Messages: 55
Registered: November 2004
Member
[Deutsche Fassung siehe unten]

Dear colleagues

While working with the <ocpTT> in the context of mapping between railML
and NeTeX, I noticed redundancies that I would like to submit to the
community for discussion and resolution for railML 2.5 and Wiki:

1) Specification of the track and platform at a stop.

The specification of
<timetable><trainParts><trainPart><ocpsTT><ocpTT>@trackInfo (see
https://wiki2.railml.org/wiki/TT:ocpTT)
seems redundant to
<timetable><trainParts><trainPart><ocpsTT><ocpTT><stopDescription ><trackInfo>@track
(see https://wiki2.railml.org/wiki/TT:trackInfo_stopDescription).

Here I would suggest to declare <ocpTT>@trackInfo as deprecated and put
an explanation in the wiki about the usage of
<ocpTT><stopDescription><trackInfo>. This is mainly because
<stopDescription><trackInfo> offers, in addition to the specification of
@track, the specification of @platform and a distinction by traffic days
via @operatingPeriodRef.

Note: The technically extended and more consistent option of linking
tracks, platforms and platform sections/sectors via a reference from
<timetable><trainParts><trainPart><ocpsTT><ocpTT>@trackRef to
<infrastructure><tracks><track> is not affected by this. However, in my
opinion, both possibilities should be described more clearly in the wiki.

2) Shunting times in the station

The specification of
<timetable><trainParts><trainPart><ocpsTT><ocpTT>@shuntingTime (see
https://wiki2.railml.org/wiki/TT:ocpTT)
seems redundant to
<timetable><trainParts><trainPart><ocpsTT><ocpTT><stopDescription ><stopTimes>@shuntingTime
(see https://wiki2.railml.org/wiki/TT:stopTimes).

Again, I would suggest declaring one of the two values deprecated and
putting an explanation of its use in the wiki. From a technical point of
view and on the part of the programmes that use it, I am not in a
position to judge which value should continue to be used.

What do you think about this?



Geschätzte Kollegen

Bei der Beschäftigung mit dem <ocpTT> im Rahmen des Mappings zwischen
railML und NeTeX sind mir Redundanzen aufgefallen, welche ich der
Community gern zur Diskussion und Behebung für railML 2.5 und Wiki
vorlegen möchte:

1) Angabe des Gleises und Bahnsteiges an einem Halt

Die Angabe von
<timetable><trainParts><trainPart><ocpsTT><ocpTT>@trackInfo (siehe
https://wiki2.railml.org/wiki/TT:ocpTT)
scheint redundant zu
<timetable><trainParts><trainPart><ocpsTT><ocpTT><stopDescription ><trackInfo>@track
(siehe https://wiki2.railml.org/wiki/TT:trackInfo_stopDescription) zu sein.

Hier würde ich vorschlagen, die <ocpTT>@trackInfo als deprecated zu
erklären und im Wiki eine Erklärung zur Nutzung von
<ocpTT><stopDescription><trackInfo> anzubringen. Dies vor allem, weil
<stopDescription><trackInfo> neben der Angabe von @track auch noch die
Angabe von @platform und eine Unterscheidung nach Verkehrstagen über
@operatingPeriodRef bietet.

Hinweis: Die fachlich erweiterte und konsequentere Möglichkeit, die
Gleise, Bahnsteige und Bahnsteigabschnitte/-sektoren über eine Referenz
von <timetable><trainParts><trainPart><ocpsTT><ocpTT>@trackRef nach
<infrastructure><tracks><track> zu verbinden, ist davon nicht betroffen.
Es sollten meines Erachtens im Wiki aber beide Möglichkeiten klarer
beschrieben werden.

2) Rangierzeiten im Bahnhof

Die Angabe von
<timetable><trainParts><trainPart><ocpsTT><ocpTT>@shuntingTime (siehe
https://wiki2.railml.org/wiki/TT:ocpTT)
scheint redundant zu
<timetable><trainParts><trainPart><ocpsTT><ocpTT><stopDescription ><stopTimes>@shuntingTime
(siehe https://wiki2.railml.org/wiki/TT:stopTimes) zu sein.

Auch hier würde ich vorschlagen, einen der beiden Werte als deprecated
zu erklären und im Wiki eine Erklärung zur Nutzung anzubringen. Welcher
Wert weiterhin genutzt werden sollte, vermag fachlich und von Seiten der
nutzenden Programme nicht beurteilen.

Was denkt ihr darüber?

Freundliche Grüße,
--
Vasco Paul Kolmorgen - Governance Coordinator
railML.org (Registry of Associations: VR 5750)
Phone railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML2] Redudant attributes in <ocpTT> [message #2883 is a reply to message #2712] Thu, 20 January 2022 11:29 Go to previous message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior Member
Hallo Vasco,

im Rahmen der Version 2.5 sind wir (die timetable Entwicklergruppe) deinem Hinweis bezüglich des Attributs shuntingTime gefolgt. Am ocpTT wurde das Attribut als deprecated gekennzeichnet und im Wiki, sowie in sonstiger Dokumentation darauf verwiesen, dass nunmehr //stopDescription/stopTimes/@shuntingTime zu verwenden sei.

Bezüglich deiner anderen Anmerkung, sind wir deiner Anregung nicht gefolgt. Im Rahmen der Entwicklung von Version 2.4 wurde dieses Thema bereits diskutiert. Damals wurde durch die timetable Entwickler Gruppe bewusst entschieden beide Möglichkeiten beizubehalten und eine der beiden, nämlich die an der stopDescription mit der Referenz auf eine operatingPeriod zu erweitern um saisonale Gleisnutzung abbilden zu können ohne dazu jeweils einen neuen trainPart bilden zu müssen.

Trotzdem vielen Dank für deine Hinweise, sowie das aufmerksame Prüfen der Dokumentation und des Standards.

---------------

In the context of version 2.5, we (the timetable development group) followed your advice regarding the shuntingTime attribute. On ocpTT, the attribute was marked as deprecated and reference was made in the wiki and in other documentation to the fact that //stopDescription/stopTimes/@shuntingTime should now be used.

Regarding your other comment, we did not follow your suggestion. This topic was already discussed during the development of version 2.4. At that time, the timetable developer group deliberately decided to keep both options and to extend one of the two, namely the one at the stopDescription with the reference to an operatingPeriod, in order to be able to map seasonal track usage without having to create a new trainPart each time.

Nevertheless, thank you very much for your advice and for carefully checking the documentation and the standard.

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML3.2] dublicate element name itinerary
Next Topic: [railML3] Train number/identification systems
Goto Forum:
  


Current Time: Fri Mar 29 13:43:18 CET 2024