Forum: railML.infrastructure » [railML3] transfer times for connections

Home » railML newsgroups » railML.infrastructure » [railML3] transfer times for connections (Request for modelling of transfertimes from platform to platform in context of connecting trains)

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

[railML3] transfer times for connections [message #2380]

Mon, 09 March 2020 15:22

Milan Wölke
Messages: 150
Registered: April 2007

Senior Member

Hello from the timetable developer group,

we have been discussing the modelling of train connections for railML 3.2 TT recently. For that we have been reviewing the modelling of connections in railML 2.x.
We discovered the attribute @minConnectionTime which currently (railML 2.x) is located at the connection element in timetable. It encodes the transfer time between the feeder and the connector, so the time that a connecting train will have to wait after the feeding train has arrived. Since in 2.x this time is encoded at the connection we redundantly need to specify the transfer time between the same platforms over and over again.
One of the goals we have set ourselves for railML 3.2 was to avoid redundancies if possible. Thus we came to the question, I'd like to share here with a broader audience, if it were possible to specify the time necessary for a passenger to change from one platform to another in the context of infrastructure.

What do you think?

Best regards, Milan

Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3] transfer times for connections [message #2382 is a reply to message #2380]

Mon, 09 March 2020 16:13

christian.rahmig
Messages: 474
Registered: January 2016

Senior Member

Dear Milan,

interesting idea indeed...
From what I understand, the transfer time is a (static) information that describes the time needed to get from one platform to another one. This means, that the information should be connected to a <platform> element? And for each platform the information occurs several times (#platforms-1). Or is there another / better element that should be used for this information?

But before we dive into modelling, let's ask the most important question: Who needs this information and for which purpose / application? I am interested in your feedback...

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3] transfer times for connections [message #2383 is a reply to message #2382]

Mon, 09 March 2020 21:44

Dirk Bräuer
Messages: 313
Registered: August 2008

Senior Member

Dear coordinators,

> But before we dive into modelling, let's ask the most
> important question: Who needs this information and for which
> purpose / application?

The minConnectionTime is needed
- as an input to the construction phase of a timetable to define the minimum time difference between arrival and departure to secure a connection,
- for a given timetable in the reverse sense, to calculate which connections can be reached / are offered and which not,
- in the operational phase to calculate prognoses due to late running while maintaining connections.

It is neither an infrastructure nor a strict timetable value; we rather regards it as a traffic-preset value. But for instance, calender data (timetable and operating periods) are the same character of information and in railML are assigned to <timetable>, so I also would assign them to timetable.

> From what I understand, the transfer time is a (static)
> information that describes the time needed to get from one
> platform to another one. This means, that the information
> should be connected to a <platform> element? And for each
> platform the information occurs several times
> (#platforms-1).

The information is not strictly static; it may change from time to time. It is typically static for a timetable period, which again is an argument to assign it at or somewhere near timetable periods.

Yes, it can be assumed to a matrix (#platforms x #platforms-1), but typically it can be eased with only 2-3 actually different values per station: 1) same platform, 2) near platform, 3) far platform (often no difference between 2-3).

So, a complete description could be something like:
<minConnTimes default="5" [mins]>
<minConnTime fromPlatformRef="pltf_1" time="3" [mins]>
<toPlatform ref="pltf_2a">
<toPlatform ref="pltf_2b">
<toPlatform ref="pltf_4">
<\minConnTime>
<\minConnTimes>

The attribute <minConnTimes>@default would apply for all combinations which are not mentioned.

Since <platform>@id's are unique in all the railML file, the <minConnTimes> list would not need to be placed at a certain <ocp> nor <platform> and can be placed at <timetable>. This allows giving <minConnTime>s which for connection between two <ocps>, as it would be necessary between two <ocp>s belonging to the same station (e. g. Berlin Hbf unten / oben / S-Bahn) or which are very close (Nordhausen <-> Nordhausen Nord).

Dirk.

Report message to a moderator

Re: [railML3] transfer times for connections [message #2384 is a reply to message #2382]

Mon, 09 March 2020 21:46

Dirk Bräuer
Messages: 313
Registered: August 2008

Senior Member

Report message to a moderator

Re: [railML3] transfer times for connections [message #2826 is a reply to message #2384]

Thu, 09 September 2021 20:12

Stefan Wegele
Messages: 4
Registered: November 2016

Junior Member

Dear all,

I think it is a shared opinion, that we need some kind of matrix with transfer times. The question is, in which schema to put it: Infrastructure or Timetable.
I would vote for the infrastructure due to the following reasons:
- The matrix uses only elements from the infrastructure, so from the architectural point of view it would not create additional dependencies between schemata.
- The times for passengers-movement are quite similar to the times for train-movements - both are defined by the infrastructure (to a large extent).
- It is possible, that the transfer-times are not constant - if in a station an escalator is defect, the transfer times should be increased similar to the train-runtimes due to TSR. The workflow for management of TSRs and transfer-times could be similar, and both use only the infrastructure-schema.

Stefan

Report message to a moderator

Re: [railML3] transfer times for connections [message #2857 is a reply to message #2826]

Tue, 07 December 2021 10:22

Milan Wölke
Messages: 150
Registered: April 2007

Senior Member

Dear all,

in the last phone conference of the timetable developers we discussed our position on this issue. A majority of the timetable developers voted for having this information in timetable. Among other things transfer times were seen as related to passengers and thus rather timetable than infrastructure. Another argument was that transfer times are a central part of connection modelling and therefore should be defined by timetable as the connections are part of timetable as well. If there is no veto on this, we would accordingly introduce some kind of matrix like structure in the root of timetable v3 in order to allow central modelling of default minimum transfer times, probably with optional linking to the timetable period.

Best regards, Milan

Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3] transfer times for connections [message #2929 is a reply to message #2857]

Tue, 01 March 2022 11:18

Milan Wölke
Messages: 150
Registered: April 2007

Senior Member

Hi all,

to continue this topic I have prepared a draft of what we could add in timetable:

https://forum.railml.org/userfiles/2022-03-01_railml_railml3-connectiontransfertimes.png

Basically we would add this directly below <timetable> as a list of <connectionTransferTime> elements. Each would refer to a startLocation and to a set of transferLocations. I used locationRef, platformEdgeRef and trackRef as values to identify the location because we are using exactly this set of values to identify where a train is stopping in timetable. As Dirk pointed out transfer times may change from time to time, thats why I added an optional reference to a timetable period to the <connectionTransferTime> element. The whole structure would look like this in XML:

<timetable>
  <timetablePeriods>
    <timetablePeriod id="ttp-1" startDate="2022-01-01" endDate="2022-06-30"/>
  </timetablePeriods>
  <connectionTransferTimes>
    <connectionTransferTime timetablePeriodRef="ttp-1">
      <startLocation locationRef="op-1" trackRef="tr-4"/>
      <transferLocations>
        <transferLocation locationRef="op-1" trackRef="tr-3" duration="PT3M"/>
        <transferLocation locationRef="op-1" trackRef="tr-2" duration="PT3M30S"/>
        <transferLocation locationRef="op-1" trackRef="tr-1" duration="PT4M"/>
        <transferLocation locationRef="op-2" duration="PT7M"/> <!--some nearby OP, no matter which track over there-->
      </transferLocations>
    </connectionTransferTime>
    <connectionTransferTime timetablePeriodRef="ttp-1">
      <startLocation locationRef="op-2"/>
      <transferLocations>
        <transferLocation locationRef="op-1" trackRef="tr-4" duration="PT7M"/>
        <transferLocation locationRef="op-1" trackRef="tr-3" duration="PT5M"/>
        <transferLocation locationRef="op-1" trackRef="tr-2" duration="PT5M"/>
        <transferLocation locationRef="op-1" trackRef="tr-1" duration="PT5M"/>
      </transferLocations>
    </connectionTransferTime>
  </connectionTransferTimes>
</timetable>

Semantically the idea would be that this matric of transfertimes would be the basic configuration of transfer times. A connection can always specify a transfertime that is different from this and would override the basic configuration that way.

What do you think of this? If you have ideas on how to improve the modelling or have additional requirements that need considering, please let me know.

Thanks in advance.

Best regards, Milan

Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3] transfer times for connections [message #2932 is a reply to message #2929]

Thu, 03 March 2022 15:40

Christian Rößiger
Messages: 63
Registered: March 2015

Member

Hello Milan,

Thank you for your draft. I have a few comments:

- For me it would be sufficient if the transfer times were only defined
between platforms (and not between tracks). There are stations with
several platforms on one track (either one behind the other or on both
sides of the track), so the reference to platforms would fit better.
- We need to specify whether a transfer time between two platforms is
valid only in the specified direction or in both. Different walking
times per direction may occur if some walkways are defined as one-way only.
- The design implies that all relations between all platforms of a
station have to be mapped, which leads to a large number of relations
with potentially identical transfer times. I would rather specify a
default transfer time for all relations within one station and then
explicitly define only those relations that have deviating transfer times.

Best regards
Christian Rößiger
------------------------------------------------------------ ---------

Hallo Milan,
danke für deinen Entwurf. Ein paar Anmerkungen dazu:

- Mir würde es genügen, wenn die Transfer-Zeiten nur zwischen
Bahnsteigen (und nicht zwischen Gleisen) definiert würden. Es gibt
Bahnhöfe, in denen an einem Gleis mehrere Bahnsteige angeordnet sind
(entweder hintereinander oder auf beiden Seiten des Gleises), daher
würde der Bezug auf die Bahnsteige besser passen.
- Wir müssen festlegen, ob eine Transfer-Zeit zwischen zwei Bahnsteigen
nur in der angegebenen Richtung gilt oder in beiden. Unterschiedliche
Gehzeiten pro Richtung können sich ergeben, wenn z.B. manche Gehwege als
Einbahnstraßen definiert sind.
- Der Entwurf impliziert, dass alle Relationen zwischen allen
Bahnsteigen einer Betriebsstelle abgebildet werden müssen, was zu einer
großen Anzahl Relationen mit potnetiell identischen Transfer-Zeiten
führt. Aus meiner Sicht wäre es wünschenswert, eine
Default-Transfer-Zeit für eine Betriebsstelle angeben zu können und nur
die davon abweichenden Relationen explizit angeben zu müssen.

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

Report message to a moderator

Re: [railML3] transfer times for connections [message #2936 is a reply to message #2932]

Mon, 07 March 2022 17:41

Milan Wölke
Messages: 150
Registered: April 2007

Senior Member

Hi Christian,

thank you for your feedback.

Quote:

- For me it would be sufficient if the transfer times were only defined
between platforms (and not between tracks). There are stations with
several platforms on one track (either one behind the other or on both
sides of the track), so the reference to platforms would fit better.

I had included the tracks because it cannot be assumed that platforms are always included in infrastructure. But I'm sure that can be discussed.

Quote:

- We need to specify whether a transfer time between two platforms is
valid only in the specified direction or in both. Different walking
times per direction may occur if some walkways are defined as one-way only.

I also see it that way. That's why I had chosen the terms startLocation and transferLocation, but you're right, that definitely needs to be clearly defined in the documentation.

Quote:

- The design implies that all relations between all platforms of a
station have to be mapped, which leads to a large number of relations
with potentially identical transfer times. I would rather specify a
default transfer time for all relations within one station and then
explicitly define only those relations that have deviating transfer times.

I think this is a good idea. This would provide a default transfer time for all connections originating from an OP, which can then be overwritten individually on 2 levels. Firstly as a transfer time between 2 platforms/tracks and secondly individually per connection. I have modelled this and added it as a new screenshot below.

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

danke für dein Feedback.

Quote:

- Mir würde es genügen, wenn die Transfer-Zeiten nur zwischen
Bahnsteigen (und nicht zwischen Gleisen) definiert würden. Es gibt
Bahnhöfe, in denen an einem Gleis mehrere Bahnsteige angeordnet sind
(entweder hintereinander oder auf beiden Seiten des Gleises), daher
würde der Bezug auf die Bahnsteige besser passen.

Ich hatte die Gleise mit aufgenommen, weil man nicht davon ausgehen kann, dass Bahnsteige immer mit in der Infrastruktur erfasst werden. Aber das kann man sicher diskutieren.

Quote:

- Wir müssen festlegen, ob eine Transfer-Zeit zwischen zwei Bahnsteigen
nur in der angegebenen Richtung gilt oder in beiden. Unterschiedliche
Gehzeiten pro Richtung können sich ergeben, wenn z.B. manche Gehwege als
Einbahnstraßen definiert sind.

Sehe ich auch so. Deswegen hatte ich die Begriffe startLocation und transferLocation gewählt, aber du hast Recht, dass muss auf jeden Fall in der Dokumentation klar definiert werden.

Quote:

- Der Entwurf impliziert, dass alle Relationen zwischen allen
Bahnsteigen einer Betriebsstelle abgebildet werden müssen, was zu einer
großen Anzahl Relationen mit potnetiell identischen Transfer-Zeiten
führt. Aus meiner Sicht wäre es wünschenswert, eine
Default-Transfer-Zeit für eine Betriebsstelle angeben zu können und nur
die davon abweichenden Relationen explizit angeben zu müssen.

Die Idee finde ich gut. Damit würde also für alle Anschlüsse, die von einem OP ausgehen eine Default Transferzeit vorgesehen werden, die dann individuell auf 2 Ebenen überschrieben werden kann. Einmal als Transferzeit zwischen 2 Bahnsteigen/Gleise und andererseits individuell pro Anschluss. Ich habe das mal modelliert und als neuen Screenshot unten angefügt.

Best regards, Milan

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

https://forum.railml.org/userfiles/2022-03-07_railml_railml3-connectiontransfertime2.png

Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3] transfer times for connections [message #2950 is a reply to message #2936]

Thu, 10 March 2022 13:11

Milan Wölke
Messages: 150
Registered: April 2007

Senior Member

Hi all,

during todays timetable developer telco we discussed the proposed modelling. We changed it slightly and came to this approach:

https://forum.railml.org/userfiles/2022-03-10_railml_railml3-connectiontransfertime3.png

The following changes have been applied:

* We moved the defaultTransferTime up to the ConnectionTransferTimeForOP. This was a mistake in the previous modelling. It should be possible to specify that all transfers within a station take X min without specifying from where to start.
* The ConnectionTransferTime.startPoint now is optional. This was introduced to allow specifying that the transfer time from OP1 to OP2 is a certain duration without having to specify which platform or track to originate from. This is especially useful when looking at connections that are available between stations that are quite far apart, such as connections between the various stations in Paris.
* We added a collection class (TransferRelations) for reasons of consistency

From my point of view this provides a good level of flexibility when specifying transfer times. Its possible to describe them on a very generalized level or one could micromanage transfertimes or choose any level of detail in between, all based on a simple set of elements.

What do you think? Any feedback is welcome.

---

Bei der heutigen Sitzung der Timetable Developer haben wir die vorgeschlagene Modellierung diskutiert. Wir haben sie leicht verändert und sind zu diesem Ansatz gekommen:

Die folgenden Änderungen wurden vorgenommen:

* Wir haben die defaultTransferTime auf die ConnectionTransferTimeForOP verschoben. Dies war ein Fehler in der vorherigen Modellierung. Es sollte möglich sein, festzulegen, dass alle Transfers innerhalb einer Station X Minuten dauern, ohne anzugeben, von wo aus sie beginnen.
* Die Angabe ConnectionTransferTime.startPoint ist nun optional. Dies wurde eingeführt, um anzugeben, dass die Umsteigezeit von OP1 nach OP2 eine bestimmte Dauer beträgt, ohne dass angegeben werden muss, von welchem Bahnsteig oder Gleis aus gestartet werden soll. Dies ist besonders nützlich, wenn es um Verbindungen zwischen Bahnhöfen geht, die weit voneinander entfernt sind, wie z.B. Verbindungen zwischen den verschiedenen Bahnhöfen in Paris.
* Wir haben aus Gründen der Konsistenz eine Auflistungsklasse (TransferRelations) hinzugefügt.

Meiner Meinung nach bietet dies ein gutes Maß an Flexibilität bei der Angabe von Umsteigezeiten.Es ist möglich, sie auf einer sehr allgemeinen Ebene zu beschreiben, oder man kann die Umsteigezeiten bis ins kleinste Detail regeln oder jede beliebige Detailstufe dazwischen wählen, alles auf der Grundlage einer einfachen Gruppe von Elementen.

Was denkt ihr? Feedback aller Art ist willkommen.

Best regards, Milan

Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Mon, 14 March 2022 15:08]

Report message to a moderator

Re: [railML3] transfer times for connections [message #2962 is a reply to message #2950]

Thu, 17 March 2022 15:24

David Lichti
Messages: 20
Registered: December 2020

Junior Member

I fiddled around with this model and found it quite convincing in its flexibility and coverage. As a result, here are somme suggestions:

Turn the startOP, and transferOP into attributes of their respective parent elements. At least with the current modelling, this does not change the data structure, but it would be more compact (and feel more natural, too).
Remove the intermediate transferRelations and transferPoints elements, since they are pure container elements where the respective parent elements connectionTransferTime and transferRelation already seem to be fitting for that role.
Add an optional platformRef attribute, since the transfer times from/to the two platform edges of the same platform will be identical in almost all cases, effectively halving the amount of text needed for the same data.
Add a default transfer time for same-platform transfers. While the defaultTransferTime avoids the quadratic number of very similar platform-to-platform times, there still is the linear number of same-platform times, which will often be even more similar.

Report message to a moderator

Re: [railML3] transfer times for connections [message #2963 is a reply to message #2962]

Thu, 17 March 2022 16:29

Milan Wölke
Messages: 150
Registered: April 2007

Senior Member

Hi David,

thanks for your feedback. All valid points and interesing suggestions. I adapted the model like this:

https://forum.railml.org/userfiles/2022-03-17_railml_railml3_connectiontransfertime4.png

Let me know what you think. My intention is to include this also in the railML 3.2 beta 3 which is going to be published early next week.

Best regards, Milan

Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Previous Topic:	[railML 3.2] "isSpeedSignal": Suggestion to delete the value "midOfTrain" of element "trainRelation"
Next Topic:	[railML3] ETCS signal/panel

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sun Nov 03 20:52:31 CET 2024