Pagination not fully implemented

[fabian]

Pagination is currently not supported by https://timetable.search.ch/api/help#route

Currently implemented with a workaround by fetching max results and then slicing them: https://github.com/OpendataCH/Transport/commit/75e962d6d7bc2ddd294cb61311f994c6e542e182

[CedricReichenbach]

In particular, negative page numbers stopped working. I'm aware this isn't part of the spec (only supporting 0-10), but previously, you could pass in a negative page number and receive connections previous to the given timestamp. This is particularly useful when browsing a connection list and wanting to load (seamlessly) later or earlier ones.

[helbling]

This can be implemented using the pre= parameter for the subrequest to timetable.search.ch as described in https://oev.search.ch/api/help#route

[fabian]

@CedricReichenbach I've implemented the negative pagination now with the pre parameter. -3 to 3 are working now.

[CedricReichenbach]

@fabian Amazing! The standard case works perfectly well now.

However, I just noticed that paging seems to be ignored if isArrival is set to true (1); the same connections are returned in either case, e.g.

http://transport.opendata.ch/v1/connections?from=thun&to=bern&isArrival=1&page=1

and

http://transport.opendata.ch/v1/connections?from=thun&to=bern&isArrival=1&page=-2

To me, it looks like those params are just redirected to the search.ch API, so the issue might be there?

[coffeemakr]

The pagination doesn't seem to work correctly when a limit is set. The two links return exactly the same result:

https://transport.opendata.ch/v1/connections?from=Basel&to=Baden&limit=6&page=2&time=21%3A41&date=2017-08-13
https://transport.opendata.ch/v1/connections?from=Basel&to=Baden&limit=6&page=3&time=21%3A41&date=2017-08-13

Lower pages have overlapping results. It this a bug or am I using it wrong?

[fabian]

@CedricReichenbach Hmm yes, can't see any obvious mistake in the code that would explain why isArrivalTime wouldn't work. Feel free to investigate further.

[fabian]

@coffeemakr This is due to the limitations of https://timetable.search.ch/api/help#route. The max number of connections is 16: so the request for page 3 with limit 6 would need (3 + 1) * 6 = 24 results, which gets capped by timetable.search.ch.

[CedricReichenbach]

Ok, the isArrival issue indeed seems to root in the search.ch API: If time_type=arrival is given, additional connections by pre will be added after rather than before the base ones.

Example: https://fahrplan.search.ch/api/route.json?from=Thun&to=Bern&time=12:00&time_type=arrival https://fahrplan.search.ch/api/route.json?from=Thun&to=Bern&time=12:00&time_type=arrival&pre=3

Since I couldn't find any proper place to report bugs, I submitted my findings through their support form. If anyone knows a better channel, please let me know. 🙂

[helbling]

The current behaviour of time_type=arrival is that num and pre arguments are switched. The reason is that in our implementation the arrival mode does everything backwards.

I agree that this is confusing and it should not be that way. I will try to fix the fahrplan.search.ch api.

[CedricReichenbach]

@helbling Is there any ETA for this? If I'm not mistaken, it causes the current output of fahrplan.opendata.ch for paginated arrival times to be mostly nonsense. Just let me know if I can be of any assistance.

[helbling]

It wasn't nonsense, it was just pre and num switched for time_type=arrival. I have now changed this behaviour so pre is always backwards in time and num forwards. Note that the default for time_type=arrival is pre=4&num=0 (and for time_type=depart as before pre=0&num=4).

[CedricReichenbach]

Great, looks much better now!

There's just one irregularity left: Pages 0 and -1 return the same results (on transport.opendata.ch). Further pages (1, 2, ... and -2, -3, ...) then work as expected by seamlessly providing later/earlier connections.

This might have something to do with num=X returning X+4 results (on fahrplan.search.ch, e.g. this), as the "overlap" of connection in paging is exactly 4 as well. If I'm not mistaken, the current behavior is as follows:

    | num --->
   <--- pre |
-o-o-o-o-o-o-o-o-o-o-
            ^ time

Is this correct, and is this expected behavior?

As far as I can tell, the current transport.opendata.ch implementation would expect something like that:

          | num --->
 <--- pre |
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
                  ^ time

[fabian]

With the pull request from @CedricReichenbach this should be resolved. Thanks!