aboutsummaryrefslogtreecommitdiff
path: root/lib/Extrapolation.hs (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Server.Ingest: new handling of unassigned trackersstuebinm6 days1-12/+12
| | | | | | | | now takes all potential stops along each trip into account when guessing tickets; also checks if a ticket is still likely in case the tracker switched its direction. This should solve many cases where a tracker is accidentally turned off or falls asleep halfway before the last station of one trip, then wakes up in the middle of the next.
* restructure: get the tracker to work againstuebinm2024-05-021-4/+5
| | | | | | | | | | | | | | | This should hopefully be the final (major) part of the restructuring: a tracker no longer has to know which trip it is on (and indeed it has no idea for now), instead the server keeps state about which trips are currently running and will insert incoming pings in a hopefully reasonable manner, based on their geoposition & time. There's lots of associated TODO items here (especially there should be manual overrides for all this logic in the web ui), but that's work for a future me. (incidentally, this also adds support for sending all log messages out via ntfy-sh)
* restructure: save a ticket's stop in the databasestuebinm2024-04-241-60/+83
| | | | now mostly independent of the gtfs, but still no live-reloading of it.
* restructure: have "tickets" independent of gtfsstuebinm2024-04-201-12/+10
| | | | | | this is mostly meant to guard against the gtfs changing under tracktrain, and not yet complete (e.g. a ticket does not yet save its expected stops, which it probably should).
* general housekeepingstuebinm2024-04-171-9/+5
| | | | | jumps to GHC2021 as default language, adds in some fields, moves the old org mode glossary to markdown, etc.
* remove some extrapolation bugsstuebinm2022-09-141-52/+57
|
* gtfs realtime: add tripUpdate feedstuebinm2022-09-101-12/+5
|
* fix the close-to-a-station bugstuebinm2022-09-091-22/+31
| | | | | | (previously tracktrain could end up in a situation where the next and last station weren't actually adjacent stops, which messed up the prediction)
* reasonable delay forecastsstuebinm2022-09-021-36/+55
|
* guess at future delays (horrible, incorrect, and unfinished)stuebinm2022-08-311-27/+42
|
* some config thingyesodstuebinm2022-08-281-3/+3
| | | | | works kinda well, but doesn't complain about unknown config values in json, which is kinda hmpf tbh
* this does way too much tbh (also functioning delays)stuebinm2022-08-281-0/+97
most of it deals with timezones, and all the weird implications that has