Nearest departures ignores some stops

[mikaelbr]

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:

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]

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]

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

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]

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]

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

[torfjor]

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]

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]

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

[mikaelbr]

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

[torfjor]

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]

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]

Given any more thoughts on this, @torfjor ?

[torfjor]

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