MoNav Map Packages
Christian Vetter
The MoNav Map Package format currently uses LZMA to compress its
blocks. While this ensures a highly compressed file, the decompression
can be quite slow ( 2MB/s on my N900 ). I am thinking of switching to
zlib compression. Qt already supports this ( qcompress, quncompress ),
therefore it wouldn't add any dependencies.
As of now we do not use this file format, but the auto-downloader will use it.
We could also offer to support both compression schemes, however I do
not really warm to the idea of having unused and untested code.
What do you think?
Regards,
Christian Vetter
Christoph Eckert
> We could also offer to support both compression schemes, however I do
> not really warm to the idea of having unused and untested code.
>
> What do you think?
the question is whether we use packages to save disk space or to ease the
download of map material (or both).
On the server and bandwidth side, compression is a good thing. On the client
side (especially on mobile devices) it is a "bad" thing. Additionally, for
uncompression, you need additional disk space, which may lead to a situation
where you have enough space left on the mobile for the data, but you cannot
use it as you do not have space left for extraction.
As the heretic I am - a third option was to use an uncompressed container
format which MoNav reads directly, without unpacking it. We could even use
some file based filesystem container (a friend of mine recently experimented
with one).
--
Beste Grüße,
Best regards,
ce
Christian Vetter
On Mon, May 23, 2011 at 8:07 PM, Christoph Eckert <c...@christeck.de> wrote:
> Additionally, for uncompression, you need additional disk space, which may lead to a situation
> where you have enough space left on the mobile for the data, but you cannot
> use it as you do not have space left for extraction.
The MoNav Map Package format is designed in a way that allows for
unpacking while downloading ( without writing the packed version to
disk ). This would only lead to problems if the unpacking would be
slower than downloading, which should not be the case.
> As the heretic I am - a third option was to use an uncompressed container
> format which MoNav reads directly, without unpacking it. We could even use
> some file based filesystem container (a friend of mine recently experimented
> with one).
Reading files from a container makes memory mapping / accessing them
more difficult on some systems ( 4GB limits etc ).
Regards,
Christian
Christoph Eckert
> The MoNav Map Package format is designed in a way that allows for
> unpacking while downloading ( without writing the packed version to
> disk ). This would only lead to problems if the unpacking would be
> slower than downloading, which should not be the case.
OK, this takes the wind out of my sails :) . Doesn't this mean that zlib is a
good compromise between compression strength and the limited horse power of a
mobile?
feverzsj
considering the original file size, I think compression for whole file
is not so helpful especially for mobile device.
If it is possible, more internal work like compressing by block or even
change the whole format could be done to decrease the whole file size.
regards, zsj