Notices

How about something less ambitious, like aggregating the 256x256 map tiles into (for example) 1024x1024 units for storage and retrieval? Sure, there would still be some wastage for featureless regions (ocean, ice cap, etc.) but wherever detail exists, the larger tiles will better match the cluster granularity. Converting an existing map cache would be a fairly simple programming exercise, no? Maybe the "supertile" size becomes user configurable, once the code is in place.

Consider that even with FAT32, 2GB is the largest partition that will accept 512 byte clusters. The minimum becomes 1024 bytes at 4GB, 2048 at 8 GB, and so on. At the 32GB upper bound for SDHC, we're back to 8KB. So higher densities will take away nearly as much as they give, in this case.

Ahhh, I see now. So, if I read right, if one needs driving directions from Point A to Point B, one must have already downloaded this route and saved it on the Nokia 770 (assuming no internet connection once in the car). If not, entering point B's address into Maemo Mapper will not produce driving directions. Correct? So (if not connected to the net once in the car) one cannot just jump into the car and enter a destination and then receive driving directions to the destination. Is that correct?

thanks,
Neil

Yes, that is correct. Because Maemo Mapper doesn't actually have Navtec-like street data (due to license costs and space constraints), Maemo Mapper cannot itself calculate directions between two points. It outsources that processing to machines much larger than a Nokia 770/n800.

You mean like GPSDrive? Yeah, I thought about keeping GPSDrive's original 1024x1024 (or was it 1280x1024?) tile size, but downloading maps 256x256 at a time and storing them 1024x1024 at a time introduces complexities that increase both the CPU and memory requirements:

1. 1024x1024 tile size means that, although fewer tiles are loaded in order to draw the full 800x480 screen (up to 4 tiles instead of up to 12), each of those tiles is 16 times larger. The net difference is that I'd have to read 4.2 million pixels instead of 0.8 million. The amount of memory required to keep those pixels in memory also means a larger memory footprint (unless you want me to re-parse those mostly-same 6.3 million pixels every time the map is panned even a slight bit).

2. There would be two possible paths for retrieving an image: either directly from disk (1024x1024) or instead from HTTP. Two separate paths introduces additional complexity and thus increased CPU usage (and bugs). This isn't that big of a deal, until you consider the HTTP path on its own, which leads to #3.

3. In the case of HTTP, currently, Maemo Mapper uses libcurl to directly transfer the files from remote location to memory card. In order to store 1024x1024 tiles, Maemo Mapper would instead have to read and interpret the 256x256 PNG (or JPEG) data in-memory, then stitch the 256x256 tiles together, then write the data to memory card. This process is not only CPU and memory intensive, it reduces the quality of the original images because they are re-compressed using a lossy compression algorithm.

No, if I'm going to conglomerate multiple 256x256 tiles into a larger file, I might as well go the whole 9 yards and put them all into the same file.

That said, jpj, I appreciate your line of thinking. Your suggestion was good in theory, good enough for me to have considered it long and hard myself, but it doesn't work well with the way Maemo Mapper is implemented). And now, you'll have to excuse me as I go off on one of my typical little tangents (some would call them rants). The following comments are rather unrelated to your suggestion, so please don't consider it any form of disrespect toward you. (And while we're at it, don't consider any of my preceding rebuttal as disrespect, either. )

The whole reason I started writing Maemo Mapper was because GPSDrive was extremely inefficient with CPU and memory, especially on the Nokia 770's limited hardware. Let's face it, GPSDrive was designed for the desktop, and on that platform, it is very versatile. On Maemo, however, you could not even start GPS Drive if you had any other applications open.

I have tried pretty hard to make Maemo Mapper as CPU- and memory-efficient as possible, to the point where some of my optimizations would not work as well for a different screen resolutions or for different behaviors (e.g. smooth tap-and-drag panning). Yeah, it's the classic "optimize before you even know you need it" blunder, but after seeing GPSDrive struggle so hard, I thought I'd address the performance issues first and foremost.

And as an even further tangent, while I'm on the subject of performance... Regarding the n800: The added memory and CPU power of the n800 is not an excuse for an application to be more liberal with memory and CPU. Maemo Mapper was written for the 770, and it will stay usable on the 770, no matter what. In fact, my personal opinion is that, in general, the added CPU and memory capabilities of the n800 should be used not to support hungrier applications but to better support existing applications (*ahem* Opera) and to better support running multiple applications at a time. 90 MB of available memory (when no other apps are running) is not justification to use all of that memory - other applications need memory, too.

Sure, if the demand is there, then maybe (in the distant future) a "higher end" version of Maemo Mapper could be released with the n800 in mind, but I will make sure that it also runs on the 770 (albeit more slowly), and I will strive to make it just as efficient on the n800 as it is now on the 770. Who knows, maybe in the future, there will be two versions (or runtime-configurable modes of operation) of Maemo Mapper: one for lean, mean, efficiency; and one with a slightly larger memory footprint. The latter will be aimed both for 770/n800 users that don't mind allocating more memory and sacrificing some responsiveness.

But until then, I'm ruling out "enhancements" that will inordinately increase memory or CPU requirements.

jpj:

Excuse my ignorance (so far I don't own a 770/N800 but hope to soon, and my experience with flash memory cards extends only to picture taking) but a question: with a 4 GB SD card, can the user format it such it consists of two equal size partitions (ie 2GB each) and therefore benefit from the more desireable 512 byte cluster granularity ?

gnuite:

Please keep up the outstanding development work on Maemo Mapper --- I'm looking forward to using it often when I purchase my Nokia IT. Thanks. !

Thank you, gnuite, for your thoughtful and well reasoned response. I'm personally unfamiliar with GPSDrive, but I trust your analysis. We're kindred spirits in terms of programming philosophy. Much of my best work has been on resource constrained platforms, and I've also enjoyed keeping those old legacy systems in play, even while pushing new code out on the latest and greatest. People might disagree on whether it's the right thing to do, but you won't get hear any arguments from me. Bottom line: You've clearly delineated the principles that define the product, and that must be the foundation of any future roadmap. Stay true to your own vision, and we'll all benefit. [/SOAPBOX]

No need to apologize - it's a good question, which I've been wondering about myself. If memory serves me, some 770 users have partitioned their MMC cards using Linux tools, yielding (for example) a dedicated swap partition and multiple ext2/ext3 partitions. There is a compatibility downside, since Windows won't mount those filesystems (as USB mass storage) without third party help. But I believe solutions are available.

I don't know whether the same can be accomplished with FAT32, but it would be worth finding out. One option I considered would be partitioning a 4GB card with street maps on one volume and topo maps on the other. You could then toggle freely between them in Maemo Mapper, much as you can in Google Maps (minus the hybrid overlay).

If nobody else chimes in with a definitive answer, I'll try some experiments.

Yes, it is certainly possible to format a single memory card with two separate file systems. They don't even have to both be the same type. In fact, that's the premise of the "extended root file system" hack that was popular on the 770.

The problem, as jpj stated, is that the Nokia 770 (out of the box) won't automatically mount both of the file systems. It will only mount the first one, and only if it is a FAT file system. It is possible (with some as-root hacking) to set up the 770 so that it automatically mounts the second file system; it just won't show up in any of the UI's, which is fine for Maemo Mapper's use (you can still use that second partition to store a Map Cache).

One strategy that you can use is to dedicate that second partition just for maps, sized exactly to the amount of map storage that you want. Then, you can write a maemo mapper startup script that will first mount the maps partition, then start maemo-mapper, and afterward unmount the partition.

Has anyone considered using jffs2 (the format that the 770/n800 uses for the root file system) for a map partition? I'm not entirely sure, so I can't confirm this, but I think jffs2 would not suffer at all from the large-block problem, since its blocks (or "nodes") are variable size.

It's not as convenience as FAT32 (not accessible or even formattable without MTD), but maybe it's worth investigating, if someone has the time and mkfs.jffs2 handy. If you do investigate, I would advise against using compression, since the PNG and JPEG images are already highly compressed.

Gnuite,

Would it be possible (in the next version of maemo mapper) to have an option to manually configure the GPX server?
I mean, a place in the config, where we set the GPX server url.
(similar to the URI)

thanks,
lmf

Yeah, lmf, I think I can manage to fit that somewhere. Planning on writing your own GPX server?

(If yes, then, in the meantime, you can always write an entry in /etc/hosts (on your Nokia device) that maps www.gnuite.com to your server's IP address. Then just put your CGI script in the path "/cgi-bin/gpx.cgi" and you're good to go.)