Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time in connections call doesn't take into account initial walk #171

Open
samkass opened this issue Jul 19, 2017 · 4 comments
Open

Time in connections call doesn't take into account initial walk #171

samkass opened this issue Jul 19, 2017 · 4 comments

Comments

@samkass
Copy link

samkass commented Jul 19, 2017

When calling /connections, if there is an initial walk it is ignored for start time estimation, essentially making the journey start in the past.

For example, this query:
https://transport-beta.opendata.ch/v1/connections?from=47.279,8.5683&to=Z%C3%BCrich%20HB&time=21:02:00&transportation[]=s_sn_r

...has a 13-minute walk to the bus stop. The query time is 21:02, but the journey starts at 20:49 with a 13-minute walk, ending at the bus stop where the bus leaves at 21:02. It appears to be doing the search such that it finds the right bus/train/etc starting at the given time, then tacks a walk to the beginning.

(This is using the beta API)

@helbling
Copy link

The timetable.search.ch API behaves exactly like the timetable.search.ch website.
Except for now-queries (empty/missing time and date) the first result will actually be the last connection before the given time. The reasoning is, that the user might not be very exact with his given time and wouldn't see the 07:58 connection when entering 08:00 otherwise.

@samkass
Copy link
Author

samkass commented Jul 19, 2017

I did the above query at 21:02 this evening without the time parameter and it returned exactly the same response. I only added the 21:02 so my bug report would stay consistent.

So if I'm understanding you correctly, if I want the connection that leaves after the specified time, I should always pick connection #2 (if present)?

@helbling
Copy link

So then Transport API probably turns the empty time in an exact time when doing the subrequest.
This is a bug, it should just use whatever time/date was given in the input.

@fabian fabian added the beta label Jul 20, 2017
@fabian
Copy link
Member

fabian commented Jul 20, 2017

Correct, the current time if used if no time is provided.

Probably because the SBB API always required a time. Will try to check if we can simply remove that or if we still use that time somewhere for internal calculations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants