<sc6502>
Looks like I was doing two things wrong then :)
<Xogium>
oh ?
<Xogium>
also, good evening
<sc6502>
Good evening :)
<sc6502>
Yeah, I'd been putting the maps in the wrong directory all along :(:(:(
<sc6502>
Somehow /maps got lost and they we're in the parent directory.
<sc6502>
Then I'd removed one too many files from the project.
<Xogium>
oh… woops, as they say
<sc6502>
Anyway, thanks to some strace magic, I managed to track down where it was all going pear shaped.
<Xogium>
tracing is a life saver
<sc6502>
Good news, I'm now actually reading map files - woot!
<Xogium>
even to track down microcontroller bugs or kernel issues
<Xogium>
oh yeah ?
<sc6502>
Bad news, memory footprint is up to 4.5MB
<Xogium>
reading as in you understand their structure, or as in navit reads them without a problem ? :D
<Xogium>
yeah that's what I figured
<sc6502>
Well this is how navit reads them at the moment.
<Xogium>
navit for Peter is about 8 mb with a fix
<sc6502>
I'm guessing it doesn't care about memory, and just reads in a huge blob.
<Xogium>
yeah, probably
<Xogium>
we could probably reduce that blob size a bit
<sc6502>
Indeed - smaller blocks to start with, and without all the extra data in the maps.
<Xogium>
one of the things I want to try doing if we stick to linux is make the build reproducible in buildroot
<Xogium>
hmm that's actually something John had worked on and we developed a maptool script that could reliably reduce the size of maps using a mix of ogr2osm patched for our use case plus maptool from navit
<Xogium>
we took most of everything out of the map and I think we only kept the speed and road name ? I don't remember
<Xogium>
we grabbed the original shapefiles from HERE and linted them
<sc6502>
That's good to know, it probably means there is a lot of code that can just go without any trouble.
<Xogium>
yeah, where'd I put that script again
<sc6502>
I think we should be able to leave the maps in flash memory to save precious RAM. It's not like anyone drives quickly enough to be on a different road multiple times per second.
<Xogium>
ah yeah in our ogr2osm repo, the translation submodule
<sc6502>
That is, unless roads are broken up into lots of 10 metre segments all joined together.
<Xogium>
there's the convert.sh that John worked on and I made the batch_convert.sh
<Xogium>
you have to compile maptool yourself unless ubuntu provides one, but I do seem to recall the ubuntu version broken
<Xogium>
but its a navit tool
<Xogium>
best part is we can also take the one from upstream here, navit, that is, to compile maptool
<Xogium>
could also send you my prebuilt maptool binary for a quick test
<Xogium>
assuming you do have the shp files
<sc6502>
I just have the .xml/.bin files here.
<Xogium>
really
<Xogium>
thought Peter gave you the shapefiles
<sc6502>
Nope
<sc6502>
So it seems .bin files are just .zip files.
<Xogium>
yeah, they seem to be, but they contain very strange things
<sc6502>
The individual file sizes seem a lot more reasonable for what we're trying to do.
<sc6502>
If we can control how much data is RAM resident.
<Xogium>
not sure if we can control that, generally on linux when you read data it goes to ram no question
<Xogium>
at least, as far as I understand
<sc6502>
That would be just down to how much data the code decides to load.
<sc6502>
Gotta go, early start tomorrow.
<sc6502>
bye for now.
<Xogium>
yeah the navit map we linted here we took from about 8 gb of shapefiles, and we reduced them to about 3.7 mb for the smallest region of UK, up to 25 mb for the largest