Bug with boarding/alighting in raptor

[vpassama]

Hi,

We have found a bug which is involving boarding and alighting times and we could use your help on the subject because we don't know yet how to fix it.

We discovered it by testing some ODT journeys in arrival mode (we use only alighting in our data) and we got unexpected results from the journey service. The problem is that for some journeys, we have to request a greater arrival time than the expected arrival time of the corresponding VJ in order to get the solution.

For example, I have a VJ which is expected to arrive at 19h20 at the requested stop and if I want raptor to choose it as a solution, I have to request journey with a datetime at 19h30 or it won't be picked (only if the arrival stop time has alighting time). It doesn't happen for every journey, but when there is a close stop accessible by foot and a service at this other stop in the past.

I wrote some tests in order to expose the problem with alighting and boarding.

Looking at the code, we found that the problem is related to boarding/alighting in the raptor_loop function.

@eturck wrote the details looking at the algorithm:

Stop	Departure	Arrival	Alighting	Foot path
A	9:00	9:00	9:00	X
B	9:10	9:10	9:25	5 min
C	9:10	9:10	9:25	0 min

So, what we understand from here, if we ask for a journey from A to C, arriving at 9h25, non clockwise search :

• Stop C has an access duration of 0 min, stop B of 5 min.
• In the first raptor loop, we search for the best jp at stop C. We find the one with the alighting time at 9h25. Labels are updated for stop C.
• The algorithm is now "onboard" so on the next loop we move to the next stop_time, stop B, and we update it too.
• Now we have this condition. And here we have a problem :
  • previous_dt = prec_labels.dt_transfer(jpp.sp_idx) returns the arrival time requested minus the access time by foot. Here 9h25 - 5 min => 9h20.
  • To see if it's interesting to stay on the vj we compare this time to the non clockwise section_end of the current stop_time.
  • Problem is, this non clockwise section_end is the boarding_time of the stop_time => 9h10, since we have no boarding_time.
• 9h20 is strictly better than 9h10 in anti-clockwise, so we look for another stop_time arriving at B before 9h20.
• Now two things can happen :
  • If there is no service before this time, everything seems to work ok, since next_stop_time returns null, we stay onboard and keep going on our vj.
  • If there is a service before that, we find it. Problem is, that's not the service we were at just before, because the alighting time is 9h25. Even if it's quicker to walk to get from B to C, if we walk to B we miss the service. And we return a journey before 9h25.

[TeXitoi]

So, better_or_equal should not compare on the boarding but on alighting. Without boarding and alighting, this work with useless computation as the algorithm will find the same stop time, but with alighting, the stop time after is found, and boom.

Just giving !clockwise() to section_end fix the problem.

[vpassama]

Thanks !