-
Notifications
You must be signed in to change notification settings - Fork 2
Description
Hi. Cool project!
I stumbled across OSM-ESP32 and LOST when I saw bbank2 had forked the former. Chasing it upstream here, I came across Lost, which is also relevant to a potential project I've been percolating for some time. I've not committed a single line of code for it, as I'm still deciding approximately how viable it is and if I want it badly enough to actually build it. I'm sure you, too, have more projects in your head than actually make it to your keyboard. :-)
Firstly, I'm not asking you to develop either of these, but I'm curious if you've found any other projects that have. My biggest challenge in implementing either one will be to not let my experience with handheld GPS (I own over 120—I'm the GPSBabel guy) and Google's Geo products (I worked on Earth for ~13 years) taint my expectation on what I can accomplish with a $4 computer.
I'm interested in placing markers on a map. In fantasy land, they'd be like Maps' that are touchable and have events triggered and have cluster managers and such. In practical matters, the individual map tiles and practical resolution of our screen are all so small that I suspect I can forget even the orthorectification issues and just use scaled x/y by the bounding coordinates of the map and just overlay a map paddle and label just cooked on top of the map tile. That might work OK at the center and maybe acceptably well at the edges. The experience near the seams where the tiles join might be bad, but maybe that's just what you get with fifty lines of trig. Have you found anything for ESP32-class devices that would handle dozens and dozens of marker points as a layer atop a raster map like this?
Secondly, the use case I'm thinking of is an outdoor game where internet connectivity for tile fetches is far from guaranteed. I think it's absolutely practical to prescan our sets of map points while we're still connected so we can pull tiles within appropriate bounding boxes and probably at a couple of zoom levels. We can then splash up a "you are here" and a line to the active nav point, updating that from the NEMA GGS callbacks, but the interesting question is about how to store that in a convenient way. It seems impractical to just have a littlefs directory tree of ${ZOOM}/${LAT}-${LON} triplets, as that's likely many thousands of tiles for even a small area. Years of experience snaps my "everything is a nail" first approach toward
a regionated image quadtree, ala https://developers.google.com/kml/documentation/regions But I'm also pretty sure that trying to decompress and manage that on an ESP32 would make it burst into flames. It would have the nice trait of allowing an entire area to be covered in just a few large files on an SD card, but the SD accesses and decompression as we seek through them could be crushing. It might be even worse if we wanted to allow blends so we could paginate through space and not have harsh breaks at map file boundaries, but blending two adjacent tiles into three overlapping ones...horizontally and vertically. So the question: Do you know of any work done to allow offline storage of OSM tiles in a spac and time-efficient way that's easy for a civilian to manage on an SD card - quite unlike our multi-petabyte image trees we used to push around a couple of contents at once at Google.
I know it's a firehose of background to deliver two questions, but I offered that because it seems similar enough to your LOST project that you may have given those two issues some thought or perhaps seen them in your research leading you up to your successes so far.
If you haven't, and/or you just don't care - and that's OK! - please just accept my thanks for this interruption and close this ticket as you see fit.
Thank you for your time and best of luck with this