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

Nearest departures ignores some stops #16

Open
mikaelbr opened this issue Mar 24, 2020 · 12 comments
Open

Nearest departures ignores some stops #16

mikaelbr opened this issue Mar 24, 2020 · 12 comments

Comments

@mikaelbr
Copy link
Collaborator

Looks like some stops are ignored when searching for nearest departures. For instance, when searching from stop Sorgenfri, none of the actual departures from that stop is included, but the stops around is.

See example:

image

I haven't looked into this much yet, just noting it here now as I found it.

I get that we probably need to be a bit more sophisticated with nearby at some point (both UI and business logic wise). Maybe it's due to me using the nearest endpoint and should use regular departure endpoints, though, but I think it still should show up?

@torfjor
Copy link
Contributor

torfjor commented Mar 24, 2020

Could it simply be that there are very few departures from Sorgenfri?

AFAIK only bus 24 stops there.

Querying for departures from a place near Prinsens gate seems to give the expected results.

@mikaelbr
Copy link
Collaborator Author

For some reason I uploaded the wrong image. Should have been these:

image

image

As you see on the second image here, the surrounding stops are included but not Sorgenfri. 24 stops on Sorgenfri, Valgrinvegen and Anton Grevskotts.

@torfjor
Copy link
Contributor

torfjor commented Mar 24, 2020

I see. The query does the following:

Given point,

  1. Find all stops around point
  2. Find departures from stops
  3. Flatten the arrays of departures
  4. Sort departures by departure time.
  5. Reduce, keeping only departures with a unique serviceJourneyID.

So only the first departure for a given serviceJourneyID will be listed, in this example the one from Anton Grevskotts veg.

I guess this can be problematic in some cases, like the one you listed.

Maybe we should sort the departures by distance to point instead?

@mikaelbr
Copy link
Collaborator Author

Yeah I was about to say: maybe we should introduce haversine here

@torfjor
Copy link
Contributor

torfjor commented Mar 24, 2020

I just pushed an update that sorts on distance to point.

The build fails currently because of a type mismatch in @entur/sdk. It should be fixed once entur/sdk#154 gets merged

@mikaelbr
Copy link
Collaborator Author

FYI, related change: 9787558


Hm. Checking this out again now that it is deployed. Now it seems odd that departure time is random down the list.

I was imagining something like this:

  1. Find all stops around point
  2. Find departures from stops
  3. Reduce/flatMap departures with unique service journey ID selecting the departures which are closest. (haversine here).
  4. Sort by departure time.

@torfjor
Copy link
Contributor

torfjor commented Mar 25, 2020

It's sorted by expectedDepartureTime now (albeit in descending instead of ascending order 😁). Which property is used in the label in the screenshot?

@mikaelbr
Copy link
Collaborator Author

mikaelbr commented Mar 25, 2020

I saw a discussion on this around realtime, and I believe it is aimed, or am I wrong, @jleknes ?

@torfjor
Copy link
Contributor

torfjor commented Mar 25, 2020

From a recent query:

{
...
    "aimedArrivalTime": "2020-03-25T13:44:00+0100",
    "aimedDepartureTime": "2020-03-25T13:44:00+0100",
...
    "expectedDepartureTime": "2020-03-25T13:44:00+0100",
    "expectedArrivalTime": "2020-03-25T13:43:23+0100",
...
    "realtime": true,
...

}

@mikaelbr
Copy link
Collaborator Author

Yeah, doesn't that confirm that aimedXX is what is what we should use? At the very least, that is what I use in the UI now 😁

@mikaelbr
Copy link
Collaborator Author

Given any more thoughts on this, @torfjor ?

@torfjor
Copy link
Contributor

torfjor commented Apr 4, 2020

@mikaelbr Maybe I'm missing something here, but aimedXXX is always rounded to a whole minute, ie. timetable departures.

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

No branches or pull requests

2 participants