aboutsummaryrefslogtreecommitdiff
path: root/todo.org
diff options
context:
space:
mode:
authorstuebinm2024-05-02 00:19:56 +0200
committerstuebinm2024-05-02 00:19:56 +0200
commit7c6285d66c597f8619a7a6c343b3c4bc66bfc4e8 (patch)
tree15a2f120506eb869090bc6b7534538236f568238 /todo.org
parent47807812f1ea59afc802b695d2986c7a525282a3 (diff)
update todo items
largely based on things noticed on 2024-05-01, this year's first day of Ilztalbahn trains running.
Diffstat (limited to 'todo.org')
-rw-r--r--todo.org102
1 files changed, 69 insertions, 33 deletions
diff --git a/todo.org b/todo.org
index b621e53..9fa5842 100644
--- a/todo.org
+++ b/todo.org
@@ -1,43 +1,79 @@
#+TITLE: Traintrack Todos
-* TODO be consistent & use lat/lon everywhere (not lat/long!)
-
-* DONE Handle service announcements
-(per trip & day, nothing else needs to be supported)
-* DONE allow trip ping ingest via websockets
+* Bugs found 2024-05-01
+** TODO auto-reconnect of /tracker websocket fails after android has gone to sleep
+** TODO /tracker should remember its token, not constantly open a new one
+either via a cookie or url parameter & redirect
+** TODO 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 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
+** 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.
* TODO implement GTFS realtime
-(this actually doesn't look too bad?)
-** DONE do the protobuf stuff
-** DONE implement vehicle positions
-** DONE implement service alerts
-** DONE implement trip updates
-** TODO test against actual real-world applications & stuff
-* TODO frontend stuff ("leitstelle"/controlroom)
-** DONE do stuff with yesod
-** TODO auth (openID? How to test?)
-** TODO dynamic content via logging/monitoring etc.
+** 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 decent-ish config files (probably yaml … sigh …)
-** DONE basic config
-** TODO more options, esp. regarding extrapolation
-* 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
-* TODO "turn off" a specific trip (as workaround in case it's cancelled or something)
-
-* TODO do lots and lots of testing
-* DONE tracker stuff (as website)
-* IDLE monitoring stuff (at least a grafana with trains would be nice)
-probably requires a fork of that grafana package
-* IDLE somehow handle extra data (e.g. track kilometres) without polluting the GTFS
-** TODO same for "how do we know how much we can reduce delay between stops?"
-** DONE can use block_id for turnaround times
-* IDLE Handle extraordinary trips
+** 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 built 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)
+* 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 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 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