Better way to deal with lots of small map images?

When one creates map from the TrekBuddy application, there are a lots of small map image files being created. Dealing with that many small files create a lots of problems, including taking up more space on disk (since some image have size smaller than the block size on the disk), very slow transfer time between storage devices (i.e. to SD card), and other performance hits whenever one needs to do file operations like copy and move on those files.

I notice that in TrekBuddy, there is an option to re-process the images to make them larger, but anything larger than 512x512 does not work (i.e. the images created are 512x512 no matter how large I change the resolution). It is a bug (or a feature)? And how does larger map tiles influence the load speed in OruxMaps?

As the other possibility, I wonder if it is feasible (performance-wise) to store tile in zip or some other file container format. Zip is probably simplest since there is a zip library in the android. Then one only needs to deal with 1 file per map, which is much more manageable than some 20000 files.

guest wrote:When one creates map from the TrekBuddy application, there are a lots of small map image files being created. Dealing with that many small files create a lots of problems, including taking up more space on disk (since some image have size smaller than the block size on the disk), very slow transfer time between storage devices (i.e. to SD card), and other performance hits whenever one needs to do file operations like copy and move on those files.

I notice that in TrekBuddy, there is an option to re-process the images to make them larger, but anything larger than 512x512 does not work (i.e. the images created are 512x512 no matter how large I change the resolution). It is a bug (or a feature)? And how does larger map tiles influence the load speed in OruxMaps?

As the other possibility, I wonder if it is feasible (performance-wise) to store tile in zip or some other file container format. Zip is probably simplest since there is a zip library in the android. Then one only needs to deal with 1 file per map, which is much more manageable than some 20000 files.

Hi, guest;

OruxMaps works only with 512x512 pixel images. If you select another resolution + Android OruxMaps = 512x512pixel images

Zip files have got bad performance searching/extracting, it is not a good solution. I am looking for a better file format, like sqlite, or others.

In OruxMaps 2.0 sure you will see a good "one file" map format.

orux

Ha I see. I was just digging into the TrekBuddy source and realize the same thing - only 512x512 works by design

I look forward to seeing the one file map format. Thanks!

Did you hear about ecw format? It seems to be optimized for storing maps, but i didn't test it:

http://en.wikipedia.org/wiki/ECW_(file_format)

The application ttmaps, for tomtom, uses it:

Maps format

The format that was chosen for ttMaps is the ECW format, developed by the company Er Mapper, recently acquired by ERDAS.. Why use such a choice? This format has many advantages for mapping applications:

Excellent lossless compression ratio, better then that of JPEG
Rapid access to image file, at any zoom level
Ability to decompress a portion of the image without decompressing the entire file

http://jrepetto.free.fr/ttmaps/en/convert_maps.html

asperge wrote:Did you hear about ecw format? It seems to be optimized for storing maps, but i didn't test it:

http://en.wikipedia.org/wiki/ECW_(file_format)

The application ttmaps, for tomtom, uses it:

http://jrepetto.free.fr/ttmaps/en/convert_maps.html

Hi, asperge;

I was looking for information about this format. But I have not found support or libraries for java-android systems.

I need to investigate deeper this format too.

orux

There is the gvSIG application, an open source application made in Java which supports ECW:

http://en.wikipedia.org/wiki/GvSIG

Unfortunately, i can't access their website right now:
http://www.gvsig.gva.es/

It seems that it's possible to use the ECW JPEG2000 Codec SDK in java by using a JNI wrapper:

Update to latest ECW library
Though erdas (formaly ermapper) does not provide a Java SDK any more, the open source community provides an alternate JNI wrapper for the ECW C/C++ SDK from erdas. You find it here: https://gvsig.org/web/ as part of this desktop GIS (I never tried, I must admit). Just download the windows installer of the desktop version and after installation find the following files inside its folder:

30/07/2009 13.39 26.647 jecw-0.0.7.jar
22/07/2009 08.46 24.576 jecw.dll
05/02/2009 13.21 57.379 NCScnet.dll
05/02/2009 13.21 1.052.706 NCSEcw.dll
05/02/2009 13.21 69.667 NCSEcwC.dll
05/02/2009 13.21 135.203 NCSUtil.dll

http://n2.nabble.com/ECW-support-update-td3669099.html

ECW JPEG2000 Codec SDK:
http://www.erdas.com/tabid/84/currentid/1142/default.aspx

Geotools is an open source Java library that provides tools for geospatial data.:

http://geotools.org

It has a class ECWReader :

http://geotools.org/javadocs/org/geotools/coverageio/gdal/ecw/ECWReader.html

Also, Osgeo website contains references to different open source projects:

http://www.osgeo.org

For reading ecw files, you can use imageio-ext :

https://imageio-ext.dev.java.net/

asperge wrote:For reading ecw files, you can use imageio-ext :

https://imageio-ext.dev.java.net/

Thanks, asperge;

I have a lot to read now

I need to study those libraries, because all of them are for j2se-sdk platforms. Perhaps they use only android-compatible classes, and will be easily ported to android.


Thanks again,

orux