Yeah that's the url I'm using. followed you're advice from earlier & found it in an earlier post. another ? if you don't mind. since mm needs internet access 2 pull up any maps, do i need to continue saving the map folders in my docs? using alot of memory. thanks

-Derrick

If you want to be able to view the maps again later, then yes, you have to keep them in the flash file system.

thanks once again 4 the insight.

-Derrick

Gunite, many thanks for this (and for maemo mapper) - it does just what I want. For the record I was using:
"http://mt.google.com/mt?n=404&v=ap.6&x=%d&y=%d&zoom=%d"
I guess this was an older URL.

Hello everybody, and thank once more to gnuite for a wonderful app.

two questions:
1. It seems maemo mapper does not work with a proxy server. This is a serious disadvantage, some ppl only see the web through a proxy(including me ofcourse). Maybe it could just respect the $http_proxy var?
2. [irrelevant] How much time did it take you to code this app gnuite? I am very curious.

Thanks a bunch.

Keep in mind that the cluster size on the larger MMC cars will kill you. For instance, my metro area cached was was a total file size of around 57MB. Size on disk 760MB!

It would be nice if we can have areas in a compressed file that are looked at first then the filesystem based cache secondarily.

What would be even better would be a local http daemon that serves the data from a mps file . Fileformats are a pain sometimes:)

You can reduce file system internal fragmentation by using a smaller block size in your VFAT format. You can do this with the "-S" option of mkfs.vfat. I use a block size of 512 bytes.

If you are serious about cramming as many maps into your card as possible, you should use ext2 and use hard links to represent map tiles that are "the same data" - water maps are all solid blue, so you can save the additional 103 bytes per tile.

Other map storage mechanisms have been considered and discarded in favor of the RAM and CPU efficiency of using the file system (including adding and removing maps on-the-fly).

Good idea - I'll look into it for the next version.
Everything so far? Probably around 200-300 hours, including making/managing releases. Much more if you include online tech support. :)

The first version took less than 40 hours (a lot of that was spent learning about NMEA and the mercator projection). The remaining hours have been spent making everyone else happy by adding feature requests. :)

format your card in fat32 (using windows). fat32 has the cluster size 4KB (4 times smaller than fat16).

Oh yeah, a different cluster is the obvious solution (or like gnuite said use ext2 and write a proggy to ln all of the files with the same md5 to a common file). I was thinking of people possibly wanting to shuffle data of commonly used cities that do not understand this issue.

I've been playing with the idea of server. Like said, there is alot of redundant data. I could further subdivide the data and really clean house. Just rebuild the zoom level 0 and server up the rest in the 256x256 blocks.