Closed pietervdvn closed 4 years ago
It turns out that this is a combination of factors
The core issue has been identified.
The workflow used to be:
I've removed the QuickSort and replaced it by a laughably simple other algorithm - which might even perform better given that the lists often will be sorted already. (the original algorithm might even have started as a joke)
Note however that, although it works for now, I'd like to have more robust handling of this case in the future - thus: our database should do this sorting itself.
The assumption is:
If a connection
C0
has a traveltime of zero, there will be a next connectionC1
with the same departure time from the arrivalstop ofC1
.
If such a condition is met, C0
should be ordered in the list before C1
. This should be handled by 'SortWindow' as well. However, I would first like to refactor all those DB's as they are way to complicated right now for what they are doing.
This is also a partly upstream issue, where connections are teleporting
Seems like in some cases the order of stations is incorrect. See the table below, generated with
dotnet run --ctlc stops=https://graph.irail.be/sncb/stops connections=https://graph.irail.be/sncb/connections today 1hour --validate jump --filter-trip http://irail.be/vehicle/IC723/20191001 --validate jump --dump-connections trip.csv