Non-monotonic schedules in Darwin

[C S]

Hi all,

So, I've built a system where I'd like to be able to query schedules for a location within a given time range. So I need to take the schedule start date and local times and transform them into full timestamps (albeit ones that ignore the timezone).

So, rather optimistically, I've relied on the public departure time (or arrival, for termini) in a schedule being monotonic. 

My main question, is what do folks do when this doesn't hold? Do most folks either just not care, or rely on the pushport schedule correcting the incorrect version?

For example, in timetable id 20250122020500 the schedule W36563 on 2025-01-22 (from Victoria to Brighton) , apparently arrives at Brighton before the service arrives at Lewes:

  <Journey rid="202501228736563" uid="W36563" trainId="1H72" ssd="2025-01-22" toc="SN" trainCat="XX">

    <!-- other locations elided -->

    <IP tpl="HYWRDSH" act="T " planAct="T -D" plat="2" pta="00:58" ptd="01:02" wta="00:58" wtd="01:02" />

    <!-- other locations elided -->

    <IP tpl="LEWES" act="T " plat="4" pta="01:22" ptd="01:22" wta="01:22" wtd="01:22" />

    <DT tpl="BRGHTN" act="TFRM" plat="6" pta="01:16" wta="01:16" rdelay="21" />

  </Journey>

But it's not present in the pushport version:

  <uR updateOrigin="CIS" requestSource="at45" requestID="0000000000010770">

    <schedule rid="202501228736563" uid="W36563" trainId="1H72" ssd="2025-01-22" toc="SN" trainCat="XX">

    <!-- other locations elided -->

      <ns2:IP wta="00:58" wtd="01:02" tpl="HYWRDSH" act="T -D" pta="00:58" ptd="01:02"/>

      <ns2:PP wtp="01:05:30" tpl="KEYMERJ"/>

      <ns2:PP wtp="01:06" tpl="BURGESH"/>

      <ns2:PP wtp="01:12" tpl="PRSP"/>

      <ns2:DT wta="01:16" pta="01:16" tpl="BRGHTN" act="TFRM"/>

    </schedule>

Or a previous schedule file:

  <Journey rid="202501228736563" uid="W36563" trainId="1H72" ssd="2025-01-22" toc="SN" trainCat="XX">

    <!-- other locations elided -->

    <IP tpl="HYWRDSH" act="T -D" plat="1" pta="00:58" ptd="01:02" wta="00:58" wtd="01:02" />

    <PP tpl="KEYMERJ" wtp="01:05:30" />

    <PP tpl="BURGESH" plat="2" wtp="01:06" />

    <PP tpl="PRSP" plat="3" wtp="01:12" />

    <DT tpl="BRGHTN" act="TFRM" plat="3" pta="01:16" wta="01:16" />

  </Journey>

Does anyone happen to know what's actually going on here?

Thanks,

[Evelyn Snow]

Hi,

The approach I'd recommend (and the one I use) is to assume that the very first time in a schedule
occurs on the SSD, and then to step through the schedule, comparing each time to the previous time
and using these rules to determine how the date should be offset for the timestamp, if at all.

https://wiki.openraildata.com/index.php/Darwin:Schedule_Element#Ordering

Evelyn

[C S]

Hi,

Ah, I'd not spotted those. So it's probably best to assume the train has just gone back in time(!) for now.

Thanks!

[David Wheatley]

I can't help with Darwin representing time travel, but in this case the train was not due to call at Lewes, however a points failure at Keymer Junction meant the train couldn't continue south down the Brighton Mainline.

The train was instead diverted via Lewes, where it would reverse, to then continue to Brighton, hence the later scheduled arrival than the time at the destination (at the time the diverted location was added, it would've been "scheduled" at 0122) is actually correct.

I assume if you look through a push port dump, you'll find a message adding the stop at Lewes that clients would have consumed to match the first data you posted.

[rhys morgan]

hi how dus the scegling work

[Matthew Burdett]

Take a look at https://raildata.org.uk

There are several formats of "scegules" which suit a variety of purposes such as Departure boards and full timetables.

--
You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/4b3cf945-cf6e-4590-b223-5f40fcdd8c78n%40googlegroups.com.

[Evelyn Snow]

Hi Rhys,

I'm afraid this is a fairly open-ended question, it'd probably help if you're a bit more specific
about what you'd like to do with schedules, and what you're not clear on.

If you haven't already looked at it, the Open Rail Data wiki may also be of some help.
https://wiki.openraildata.com/index.php/Main_Page

Finally, you're most welcome to ask questions on the mailing list, but it'd be a help if you make
a new thread for questions which aren't related to the subject.

Evelyn

[Michael Tsang]

On Saturday, 15 March 2025 02:09:47 British Summer Time 'David Wheatley' via A

gathering place for the Open Rail Data community wrote:
> I can't help with Darwin representing time travel, but in this case the
> train was not due to call at Lewes, however a points failure at Keymer
> Junction meant the train couldn't continue south down the Brighton Mainline.
>
> The train was instead diverted via Lewes, where it would reverse, to then
> continue to Brighton, hence the later scheduled arrival than the time at
> the destination (at the time the diverted location was added, it would've
> been "scheduled" at 0122) is actually correct.
>
> I assume if you look through a push port dump, you'll find a message adding
> the stop at Lewes that clients would have consumed to match the first data
> you posted.

Unfortunately the fact that in Darwin a train can time travel violates one of
the fundamental principles of timetabling, and I am forced to lie on the
scheduled times on the diversionary route for our software to accept the
schedule (the software we use has a strict, non-negotiable requirement that
all scheduled times and actual times must be non-decreasing - this is
fundamental to how routing algorithms work).

It is extremely unhelpful to passengers when a train is diverted but the
scheduled times are not corrected later downstream. I hope that the upstream
data can be fixed so that, even in the case of diversion, the scheduled times
can still be increasing.

Michael

[Arturs Dobrecovs]

Hi Michael,

>  It is extremely unhelpful to passengers when a train is diverted but the scheduled times are not corrected later downstream. I hope that the upstream data can be fixed so that, even in the case of diversion, the scheduled times can still be increasing.

If the operator was to change the scheduled arrival time of that train at Brighton, it would essentially be lying to the passengers that the train is less delayed than it really is. Scheduled arrival and departure times should not be changed.

> <DT tpl="BRGHTN" act="TFRM" plat="6" pta="01:16" wta="01:16" rdelay="21" />

The "rdelay" attribute on the Brighton call is there to ensure that you can still order the locations in the correct chronological order, despite the scheduled times suggesting otherwise. When sorting the locations, the "rdelay" value (in minutes) should be added to the planned arrival time before any comparisons. In this case, 01:37 should be used for sorting, but 01:16 should still be the value displayed to customers.

From section 4.3.1 of the Darwin specification:

 "From version 11 of the data schema, when a service is re-routed to a new path, which then re-joins the original path, the location at which the service re-joins may have an “rdelay” attribute. This attribute provides a delay value that is implied by the change to the service's route. Darwin will add this value to the forecast lateness of the service at the previous schedule location when calculating the expected lateness of arrival at this location. A client that is expecting scheduled times to chronologically increase will need to take this value into account, since the scheduled times may jump back when the service joins its original route. Adding the “rdelay” value to the scheduled times at the location where it is defined, plus later locations, will maintain chronological order."

Kind regards,

Arturs

[Michael Tsang]

On Tuesday, 8 July 2025 19:47:00 British Summer Time Arturs Dobrecovs wrote:
> Hi Michael,
>
> > It is extremely unhelpful to passengers when a train is diverted but the
>
> scheduled times are not corrected later downstream. I hope that the
> upstream data can be fixed so that, even in the case of diversion, the
> scheduled times can still be increasing.
>
> If the operator was to change the scheduled arrival time of that train at
> Brighton, it would essentially be lying to the passengers that the train is
> less delayed than it really is. Scheduled arrival and departure times
> should not be changed.

In the case of adding additional calls onto an existing route, the scheduled
times are maintained in ascending route order even on the ground it will delay
the train. Why, in this case, the time given at Lewes is deliberately later
than the Brighton? What will happen if someone is to search for an itinerary,
using scheduled time only (disregarding the real-time delay), from Lewes to
Brighton?

Michael

[Peter Hicks]

Hi Michael

On Wednesday, 9 July 2025 at 10:41, Michael Tsang <mik...@gmail.com> wrote:

> In the case of adding additional calls onto an existing route, the scheduled
> times are maintained in ascending route order even on the ground it will delay
> the train. Why, in this case, the time given at Lewes is deliberately later
> than the Brighton? What will happen if someone is to search for an itinerary,
> using scheduled time only (disregarding the real-time delay), from Lewes to
> Brighton?

What happens depends entirely on the way the altered times are entered in to the system being queried, simple as that.

Taking a step back, it sounds very much like you're having a problem integrating the information from Darwin in to your system (Aubin?) and, rather than looking at compromises to ensure the data from Darwin matches the strict requirements of Aubin, you're trying to make it out that Darwin is wrong for not adhering to a way of working that you think it should adhere to.

Although I'm not in the habit of giving free consultancy (especially given the circumstances here), I think you have two options. You could accept that Darwin is not a perfect input source for your application and do your best when it comes to specific, infrequently seen situations such as this - or you could write a paper with the problem statement and your proposed solution, and send it to RDG for consideration the next time Darwin is updated.

The world ain't perfect.


Peter

[Tom Cairns]

I by and large agree with what Peter has to say here.

However, I would just like to pick up on one thing. Michael, your messages do seem to blur the lines between two distinctly separate trains (lol) of thought.

People would like to know what time a train leaves X to get to Y. In scheduling land, you present the time that it is scheduled to run. On the day, most people's thought processes will follow the lines of what time is it actually going to run. The differences between those two trains are small but very distinct. When a train experiences perturbation, the reality is that the schedule is then utter nonsense and largely meaningless other than for booked train only reservations which a huge number people travelling will have and delay compensation from a passenger perspective.

Imagine a scenario where you're at, say, York at 13:00 and the next train to Edinburgh is the 11:35 departure which is leaving at 14:15 due to major disruption. The passenger in reality just wants to know what time it is going to actually be there.

If you're trying to introduce actual running but still focussed on keying that based on scheduled times and wanting guarantees of ordering from that then that will not work. Personally I would in this case, if systems supported it, just say there isn't a scheduled time - it will just go there at some point (because there isn't really, just an expected one). Should the industry give out just completely random scheduled time that happens to work in the schedule to keep it linear or one that makes some level of sense? I think the reasonable expectation is probably the latter.

You could, of course, change the scheduled times during a diversion (so the Brighton arrival time becomes 01:40 or something like that) but then you will experience complaints from people saying that you're trying to fudge the performance numbers or escape delay repay etc.

There is no particularly good solution here and trying to force the railway to suit your own requirements isn't going to work and you'll need to, as Peter says, work with what you've got or propose what would be a (impressive if you manage it) complete about turn about how timetabling and scheduling is managed in disruption.

My suggestion would be to focus on delivering something well that doesn't require changing the industry around you.

Tom

> --
> You received this message because you are subscribed to the Google Groups
> "A gathering place for the Open Rail Data community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openraildata-t...@googlegroups.com.
> To view this discussion, visit
> https://groups.google.com/d/msgid/openraildata-

> talk/mvSJ27WRY1T65IwO35gulR0_Ix1yerL446zgYXuHrfBlrlSRMeYYXXOBUAvEd
> Zw4k55SLdSSx6-aiOMzASPv_S4VQlrOYsVcH8tYXqFjdBQ%3D%40poggs.co.uk.