1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
#+TITLE: Traintrack Todos
* Bugs found 2024-05-01
** PROGRESS train anchors are sorted wrong
probably based on sequence number, not based on time. results in "stuck"
nonsensical delay information if we had a mistaken geolocation in the middle
of the route too early
changed to creation date, check in production
** TODO auto-reconnect of /tracker websocket fails after android has gone to sleep
** TODO stations with longer stopovers than ~2 minutes break delay extrapolation
** TODO head-turn at Passau (Gr) breaks delay extrapolation
here the train has to stop & change direction, but is not in a station.
Stefan says this usually takes ~5 minutes. Breaks delay predictions during
that time, since we assume linear movement.
** DONE /tracker should remember its token, not constantly open a new one
either via a cookie or url parameter & redirect
** DONE do not give tripupdates after tickets are completed or outdated
** TODO tickets are not reliably marked completed
** TODO any kind of check against unrealistically fast travel?
** DONE matching of tokens to trip ought not to assume trips are at their start position
this produces horrible results if the tracker is started towards a trip's end
* TODO implement GTFS realtime
** TODO get google to accept trip updates
** DONE get google to accept service alerts
** TODO re-implement vehicle updates
* TODO web frontend ("Leitsystem")
** TODO nicer rendering for timestamps (e.g. "in three minutes", "5 seconds ago", etc.)
** TODO more cross-references (e.g. list of dates on which a trip runs)
** TODO links to osm / embed leaflet
** TODO better import workflow
be careful to deduplicate things wherever possible (e.g. shapes), and make
it easy to import single trips & <range of time>.
** TODO prevent double imports
should either error or (optionally) update the existing trip (perhaps change
the completed-field of tickets int a status: scheduled (can still be changed
by imports), in-progress (currently underway), done, archived)
* TODO build a better onboard unit
Friedrich still likes the idea of dedicated hardware (so people won't have to
remember turning it on). I kinda like the idea of an android app for the
onboard tablet. If it always displays current information, people might even
remember to turn it on (at least people were interested today – 2024-05-01)
** IDEA display a warning on it if there's another tracker for the same trip
** IDEA display a warning on it if it's > 100m away from tracks
(possibly also make the server discard data in such cases)
* TODO re-do configuration, replace conferer, possibly write own config library
conferer is okay-ish, but it cannot (?) give warnings for config items that
were e.g. misspelled in a yaml file. There's also no easy way to figure out
where a config value came from afterwards.
* TODO replace the gtfs-based sequence with my own index during import
this should enforce that the difference between stations is always exactly 1
(& possibly also that the first station is 0)
* TODO somehow handle extra data without polluting the GTFS
** TODO gtfs blocks for handling trips done by the same vehicle
** TODO everything else goes into the database & can be inserted via the web frontend
* TODO "cronjobs" that check for odd things
things like: trip is scheduled to run, but has no tracker, trip has unreasonable
delay values (< -5, > 40 or so)
* IDLE look at hasql-th for database things
https://hackage.haskell.org/package/hasql-th
this would be another major rework, but persistent really is a little annoying
to use …
* IDLE UI for entering custom / ad-hoc trips
(i.e. those outside the gtfs schedule)
* IDLE handle partially cancelled trips
* IDLE find out if we need to support VDV standards
focus on gtfs rt first
* IDLE better sql library
persistent is sometimes weird to use, and without any support for joins some
queries are just unreasonably wordy (& inefficient), requiring lots of mapM.
It also has horrible mapping for datatypes (almost all i use are natively
supported by postgres, but persistent stores most things as var char)
* done before 0.0.2
** DONE estimate delays
basically: list of known delays in a db table, either generated from
trip pings & estimates or user-defined in the control room
*** DONE properly handle timezones during gtfs parsing so no one else has to deal with that
turns out that's impossible, but it looks to be fine the way it is now
** DONE "turn off" a specific trip (as workaround in case it's cancelled or something)
** DONE do lots and lots of testing
** DONE tracker stuff (as website)
** DONE do stuff with yesod
** DONE auth (openID? How to test?)
** DONE Handle service announcements
(per trip & day, nothing else needs to be supported)
** DONE allow trip ping ingest via websockets
** DONE implement gtfs realtime
*** DONE do the protobuf stuff
*** DONE implement vehicle positions
*** DONE implement service alerts
*** DONE implement trip updates
*** DONE switch to proto-lens library
protocol-buffers is sadly undermaintained, and a bit unwieldy to use
|
