aboutsummaryrefslogtreecommitdiff
path: root/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Server.Frontend.SpaceTime: fix lots of bugsstuebinm2024-05-151-49/+54
| | | | | also make the code generally look nicer. Turns out I made a lot more fragile assumptions than I thought I did.
* Server.Ingest: new handling of unassigned trackersstuebinm2024-05-154-86/+168
| | | | | | | | 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.
* config: add a debug mode optionstuebinm2024-05-152-3/+8
| | | | | this is meant to be false by default, and otherwise relaxes requirements on e.g. incoming pings, which are inconvenient when testing by hand.
* space time diagrams: real time & time zonesstuebinm2024-05-103-86/+178
|
* rough initial work on space-time diagramsstuebinm2024-05-093-0/+107
| | | | | | this does svg templating with hamlet. It might be better to use a javascript library instead (templating svgs is a little confusing tbh), but for now i'll see how far i get with this.
* restructure: split web frontend into several modulesstuebinm2024-05-096-302/+479
|
* restructure: split up the server modulestuebinm2024-05-085-302/+394
|
* fix: tripupdates should not contain old tripsstuebinm2024-05-031-2/+2
| | | | apparently i forgot an if here?
* restructure: get the tracker to work againstuebinm2024-05-028-135/+268
| | | | | | | | | | | | | | | 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)
* correct styling on mobile devicesstuebinm2024-04-241-1/+4
|
* restructure: save a ticket's stop in the databasestuebinm2024-04-247-327/+502
| | | | now mostly independent of the gtfs, but still no live-reloading of it.
* restructure: have "tickets" independent of gtfsstuebinm2024-04-208-192/+305
| | | | | | 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-179-72/+29
| | | | | jumps to GHC2021 as default language, adds in some fields, moves the old org mode glossary to markdown, etc.
* replace protocol-buffers with proto-lensstuebinm2024-04-173-282/+198
| | | | | | I do not really like either option, but at least the second one seems more likely to be maintained (and a little less clunky to use, too, for what it's worth).
* change server timetables apistuebinm2023-05-261-1/+2
|
* expose sequence length of trip to onboard unitstuebinm2023-05-261-0/+1
|
* gtfs-rt: discard old trips from tripupdates feedstuebinm2023-05-231-7/+12
| | | | google maps complains about it otherwise
* expose the gtfs.zip used in the APIstuebinm2023-05-205-29/+49
|
* simple on-board toolsstuebinm2023-03-112-10/+26
| | | | | | these are just enough to send train positions to tracktrain with the current API, but are somewhat brittle (e.g. will fail if not restarted between trips, etc.)
* don't hardcode cssstuebinm2023-02-234-68/+10
|
* better web interface & cssstuebinm2023-01-283-30/+84
|
* switch to ghc 9.0.2stuebinm2023-01-222-27/+46
| | | | this makes the nix builds /much/ nicer
* oauth2 via uffdstuebinm2023-01-224-48/+210
| | | | | | this is unfortunately uffd-specific, since oauth2 is apparently sort of a vague standard. But since it doesn't actually do much it should probably be possible to make it fully configurable & generic if needed.
* simple realtime position mapstuebinm2022-12-133-2/+58
| | | | | (what was that about doing the realtime stuff somewhere else and /not/ in this monolithic server thingie? oh well …)
* stylish-haskell runstuebinm2022-12-123-6/+7
|
* a subscribe websocket for real-time location infostuebinm2022-12-122-7/+37
| | | | (for a leaflet map view or sth which isn't implemented yet)
* gtfs-rt: set trip_descriptor.schedule_relationshipstuebinm2022-12-031-1/+2
| | | | (hardcoded for now, since we don't have new trips)
* unreasonably stupid and probably unnecessary codestuebinm2022-12-032-5/+18
| | | | (but maybe google will like it)
* set uncertainty in gtfs-rtstuebinm2022-12-031-2/+2
|
* always display secondsstuebinm2022-12-031-2/+2
| | | | (this is a hack to make the gtfs rt valid)
* this is almost certainly bullshitstuebinm2022-12-031-6/+6
|
* let's try something else as wellstuebinm2022-12-031-1/+2
|
* another gtfs rt thingie?stuebinm2022-12-031-1/+2
|
* fix google warningstuebinm2022-12-031-1/+1
|
* controlroom: show tripShortName instead of tripIdstuebinm2022-11-292-8/+20
| | | | | since the ids really should be internal to the gtfs, and not needed in "normal" contexts.
* respect gtfs start/end datestuebinm2022-11-291-1/+4
| | | | | | not only is this a surprisingly stupid bug, i distinctly remember writing these few lines sometime ago … but they're not in the commit history, so i guess they got lost somehow??
* fix gtfs tripupdatesstuebinm2022-10-161-83/+92
|
* simple prometheus metricsstuebinm2022-10-163-7/+35
|
* remove some extrapolation bugsstuebinm2022-09-144-61/+66
|
* on-board-unit: display estimated delay etc.stuebinm2022-09-113-6/+12
|
* correct the generated openapi descriptionstuebinm2022-09-112-5/+22
|
* gtfs realtime: add tripUpdate feedstuebinm2022-09-105-33/+104
|
* use websockets for the on-board-unitstuebinm2022-09-101-32/+31
|
* 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)
* init onboard-unitstuebinm2022-09-031-0/+21
|
* reasonable delay forecastsstuebinm2022-09-024-66/+96
|
* guess at future delays (horrible, incorrect, and unfinished)stuebinm2022-08-315-43/+95
|
* some config thingyesodstuebinm2022-08-286-29/+64
| | | | | 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-286-99/+346
| | | | most of it deals with timezones, and all the weird implications that has
* controlroom: lots of pretty little knobsstuebinm2022-08-277-123/+185
| | | | (also some database schema changes, for good measure)