Notices

If you're unsatisfied with the performance of downloading/saving maps while panning, then perhaps you should consider turning off auto-downloading and pre-downloading the maps that you need. Or using no Map Cache database at all. Or a faster MMC card. The disk sync is done in a separate thread, though, so it shouldn't freeze the UI.

And yes, sgosnell was right, it only syncs after a set of downloads is complete, so if you're panning many times consecutively, that would be a single file sync. If it didn't sync at all, then you could lose data if Maemo Mapper or your device crashes.

When it pans, it accesses new maps, and (of course) all maps use north-is-up orientation. How is Maemo Mapper supposed to draw newly-accessed maps at the correct orientation without rotating them?

That, however, shouldn't matter to you if you're always using the north-is-up orientation. In that case, "map rotation" is essentially a no-op - very little--if any--actual computation is being done. This is very easy to see for yourself - map redrawing is much faster when you are at a rotation of 0 degrees (north is up).

Quick question: is any effort made to simplify rotation at the other cardinal directions? They should be fast vs. intermediate angles, though I didn't notice any difference in scrolling regardless of angle. Maybe I'll try it while paying attention...

That's basically what I did. I never download maps using N800 actually, all my map tiles downloading, poi...are managed on PC. But even that, MM2.x can not be comparable with MM1.4 in the speed.

I did some tests as well, actually putting display in the separate thread slows down the speed. I tested to use the direct call, and it turns out much fast. But I know I can't do that in the real world since if downloading runs into trouble, it will block and freeze.

I am using modified MM1.4.7 and quite happy with it. I don't need rotation, etc functions. In the new format my 129M map tiles only take 135M disk space, very good.

The chance for a crash that actually loses data is very very small though. It would basically have to be a kernel panic (i.e. a kernel error or some fatal hardware problem). Other kind of crashes (e.g. UI crash because of low memory, bug in MM, watchdog reboot) will still sync the data as part of the shutdown. On a desktop computer you can accidentally pull out the power cable, but on a battery-powered device you have to actually remove the battery.

The most likely way of losing data would probably be to yank out the memory card so fast that it can't get to sync it between when you open the door/remove the magnet (on N800) and when you rip out the card.

You have to write the data sometime, though, and it may be easier and clearer to do it explicitly when the download is finished, to minimize the possibility of data loss and to make maintenance easier. It's a design choice, and one I agree with. I don't think writing as soon as the download is over slows things significantly.

nutter,
thank you for bringing v1.4.7mm to os2008. I have used mm for several years, and have loaded mm with custom maps that I have scanned in and then tiled with mapcruncher. When you ported mm to os2008 you changed the map format to a .map file for better storage to optimize the space. This however broke my ability to edit the individual map tiles which were .jpg's. The .map files cannot be edited, they throw errors. When I scanned in a map I would fill in the 'empty' space that would happen with the tiles on the edge. This would prevent mm from crashing on what it though was a corrupted tile.
I find it very difficult to use v2.2 mm for the custom maps as accessing the tiles is troublesome, and your port would be fine, if I was able to edit the .map files or even better I had the option to keep the old .jpg format of the os2007 mm, this would be best as it allows easier editing of individual tiles. I am not sure but what would be the possibility of having a choice between the space saving .map format, which I would use for 'standard' maps, and the .jpg which could be used for 'custom' maps, where storage is less of less import?
If not maybe you could help with why the individual .map files are not editable.
thanks for your time to consider this...

Nutter, two questions.

1. Have you talked to the maemo-mapper author about switching database formats and/or integrating your mod into his program?

2. Have you considered (since you're already halfway there) creating a program for Windows and/or Linux that automatically downloads the map files for a given area and automatically builds the database? I ask this because if you've already done this, or are part way there, then there's no need for me to do my script which would essentially be duplicating your work. If not, could you consider it? It'd save me the **** of trying to learn GDBM.

Gnuite (above) is the author; as you can see, they've talked, and seem to not quite agree entirely.

Well poo.

Anyone know the status of this project mod? How does it compare to the current repository version of M.Mapper? Any dependency issues if I install this?

I'm just in the process of caching large areas and finding M.Mapper is getting very ssssslllllloooooowww while panning around. This idea is intriguing, but it's circa 2008, with nothing new posted...

Anybody using it?

Edit: So, I tried this and it works very well for my needs. I've cached pretty much everywhere I'm ever going to go and it isn't any slower in panning around than when I started. The only annoyance I've run into is that I have to remember to not upgrade to the latest version of MM, which a trivial issue. Don't know, maybe the new version of MM has solved the slow panning issue, but I'm not inclined to try it. Nutter's version works very well for me.