update with TODO list

README

@@ -44,18 +44,93 @@ of the screen
 
 random notes follow ...
 
-1) Satellite requires these commands to be run before
-it will work. 
-
-  mmcli -m 0 --enable
-  mmcli -m 0 --location-enable-gps-raw
-  mmcli -m 0 --location-enable-gps-nmea 
-  mmcli -m 0 --location-status
 
 
-2) we should make saturn give visual feedback while it's loading an
+https://git.syndicate-lang.org/tonyg/squeak-phone/raw/commit/474960ddc665ed445a1f5afb0164fe39057720f9/devices/pine64-pinephone/modem-docs/80545ST10798A_LM940_QMI_Command_Reference_Guide_r3.pdf
+
+
+
+1) [done] connect Satellite to qmi-nmea
+
+https://codeberg.org/tpikonen/satellite/src/branch/main/satellite/nmeasource.py#L106
+
+2) [nope] do we need modemmanager? might be required if we want lte data,
+but that's up to the "site admin" - we don't need it for biscuit itself
+
+3) we should make saturn give visual feedback while it's loading an
 app. How does it know when the app has finished loading?  Maybe it
 could get told when its window is obscured
 
+4) rename Maps to soemthing that describes its role better. Cockpit?
+HUD? (but it's actually H Down D)  Head Unit? Navigate? Dashboard? Cluster?
+Codriver? Satnav? Binnacle? Launch? Ride? Embark?
+
+5) [all done]
+Maps also needs to open the nmea port and parse data from it.
+5a) Maps needs to open a fake nmea source for testing
+5b) we need a generator of fake nmea data
+
+6) Cockpit
+- show [done] speed and [done] direction
+- show speed limit
+- [done] scroll and [not done] rotate map
+- overlay planned route on map
+- show next turn
+- voice prompts
+- when off-course, calculate route to nearest point on course
+- fetch planned route from nominated url
+(don't want to type the url in, is there a better way to have it check in
+with a mothership?)
+- save trail (maybe this could be a separate task entirely)
+
+elapsed time: what should it actually show? moving time, I guess
+- moving time since when?
+
+should we rename bearing as course in nmea?
+
+rotating the map is going to be complicated because the widget we're
+using doesn't support it (bitmapped map tiles)
+
+
+
+perhaps we need a server-side component for route planning
+
+
+7) think about how to use nfc tags or something for profiles so that
+it can recognise when it's attached to bicycle or motorbike
+
+
+8) use OSM directly?
+
+we can't rotate the map using OsmGpsMap widget because the labels will
+be sideways or upside down, so we need something with vectors that we
+can rotate
+
+a) we can get data from overpass api as json
+
+b) we would like to cache the results, which means some kind of
+chunking or tiling so that the json for position a is the same as the
+json for position b.
+
+c) at coarser zoom levels, we need to query for fewer objects: either 
+do it by hand -
+
+- houses
+- minor roads
+- major roads
+
+or so something smart but complicated like "only return ways that
+cover more than 1/16th the length of the tile"
+
+d) I think we will need some kind of server so that multiple users get
+the benefit of the caching. If we're going to do that, should it also
+do transformation e.g. from lat/long to x/y co-ordinates? We don't
+need this bit yet though
+
+3) alternatively we could use mapbox vector tiles, but tbh I'm
+struggling to see now that helps. we don't have to transform from
+lat/long but instead we have to parse a protobuf, how is that simpler?
+
+