some notes about tiles

README

@@ -44,18 +44,98 @@ of the screen
 
 random notes follow ...
 
-1) Satellite requires these commands to be run before
-it will work. 
 
-  mmcli -m 0 --enable
+1) [done] connect Satellite to qmi-nmea
-  mmcli -m 0 --location-enable-gps-raw
-  mmcli -m 0 --location-enable-gps-nmea 
-  mmcli -m 0 --location-status
 
+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
 
-2) we should make saturn give visual feedback while it's loading an
+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?
+
+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
+
+
+https://git.syndicate-lang.org/tonyg/squeak-phone/raw/commit/474960ddc665ed445a1f5afb0164fe39057720f9/devices/pine64-pinephone/modem-docs/80545ST10798A_LM940_QMI_Command_Reference_Guide_r3.pdf
+
+----
+
+... sod, forgot to push latest changes from noetbook
+
+we need to extend to multiple tiles'-worth of map
+
+* get tile for curent lat/long and request overpass data for enough
+  surrounding tiles to fill the screen
+
+* I think a way is served with all its nodes whether or not they're in
+the bbox, so we can just store the ids of ways we've seen and skip
+them if the come up again
+
+* render all the polylines into the widget (some day also the labels etc)
+
+* to get it centred on the cyclist, take the tile fractional part *
+  256, and translate the canvas up and left by that amount
+
+
+
+and offset
+by 
 
 

pkgs/maps/assert.fnl

@@ -17,8 +17,16 @@
                (.. "\nexpected " ve# "\ngot " va#)
                ))))
 
+(fn expect-near [actual expected]
+  `(let [delta# (math.abs (- ,actual ,expected))
+         e# ,expected
+         a# ,actual]
+     (assert (< delta# 0.00000001)
+             (..  "expected " e# " to be approximately " a#))))
+
+
 (fn define-tests [& body]
   (when _G.RUNNING_TESTS
     `(do ,(unpack body))))
 
-{ : define-tests : expect : expect=  }
+{ : define-tests : expect : expect= : expect-near }

pkgs/maps/shell.nix

@@ -2,6 +2,7 @@ with import <nixpkgs> {};
 let package = pkgs.callPackage ./. {};
 in
 package.overrideAttrs(o: {
+  nativeBuildInputs = o.nativeBuildInputs ++ [ pkgs.socat ];
   shellHook = ''
     export LUA_CPATH=$(lua -e "print(package.cpath)")
     export LUA_PATH=$(lua -e "print(package.path)")\;$RXI_JSON/share/lua/5.3/?.lua

pkgs/maps/tiles.fnl

@@ -2,6 +2,7 @@
 (local { : dict_to_query } (require :http.util))
 (local json (require :json))
 
+(import-macros { : define-tests : expect : expect= : expect-near } :assert)
 (local { : view } (require :fennel))
 
 
@@ -33,3 +34,38 @@
     (print (view headers))
     (print (view (json.decode (stream:get_body_as_string))))))
       
+(fn sinh [x] (/ (- 1 (math.exp (* -2 x))) (* 2 (math.exp (- x)))))
+
+(expect (< (math.abs  (- (sinh 2) 3.626860407847)) 0.001))
+
+(fn tile->latlon [xtile ytile zoom]
+  (let [n (^ 2 zoom)
+        lon-deg (- (/ (* xtile 360) n) 180.0)
+        lat-rad (math.atan
+                 (sinh (* math.pi (- 1 (/ (* 2 ytile) n))))
+                 )]
+
+    (values (/ (* lat-rad 180) math.pi) lon-deg)))
+
+(let [(lat lon) (tile->latlon 0 0 0)]
+  (expect= lon -180)
+  (expect-near lat 85.05112877)
+  )
+
+(let [(lat lon) (tile->latlon 232798 103246 18)]
+  (expect-near lon 139.699401855)
+  (expect-near lat 35.6595278648)
+  )
+
+(fn latlon->tile [lat lon zoom]
+  (let [n (^ 2 zoom)
+        x (* n (/ (+ lon 180) 360))
+        t1 (/ (* lat math.pi) 180)
+        t (math.log (+ (math.tan t1) (/ 1 (math.cos t1))))
+        y (* (- 1 (/ t math.pi)) (/ n 2))]
+    (values x y)))
+
+(let [(x y) (latlon->tile 52.1234 -0.53 17)]
+  (expect= (math.floor x) 65343)
+  (expect= (math.floor y) 43221))
+