diff options
| -rw-r--r-- | todo.org | 102 |
1 files changed, 69 insertions, 33 deletions
@@ -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 |