Due to poor performance and portability issues associated with raster libraries, I don’t think it’s a good idea to use raster formats such as TIFF, ECW or MrSID on mobile devices such as (smart)phones, pocket PCs, tablets, etc.
Google Maps, OpenLayers and OpenStreetMap have made quadtree tiles very popular. Initially intended to increase web mapping performance, they are a very good option to implement local raster layers on mobile devices. Instead of having a large raster file, you can copy a quadtree pyramid of tiles (usually in JPG, PNG or GIF format) to your device.
After we have created the tiles following the popular z-x-y scheme, we can write a .tpy (tile pyramid) header file to include some metadata. These metadata will be read when the application initializes the raster layer. Here is a possible header file (valencia_1704.tpy):
# First line: tile image format: JPG, PNG, GIF, etc
# Second line: tile width and height
# Third line: SRS code
# Fourth line: recommended z levels
6 7 8 9 10 11 12 13 14 15 16 17 18
# Fifth line: WKT polygon indicating covered area
POLYGON((-42850 4788700,-40700 4788700,-40700 4791200,-42850 4791200,-42850 4788700))
The final dataset structure would look like this:
What happens with z levels below 6 and over 18?
We know the quality of the initial raster, and in the metadata we are indicating that z levels beyond 18 would not provide additional information, and in the unlikely case of being needed, they should be created by resampling 18 level tiles on the fly. Levels below 6 are merely a blank tile with a dark pixel on it, so these are not useful at all.
What happens if SRS is not Spherical Mercator (EPSG:3857)?
The extent of the world tile (z = x = y = 0) is always:
Minimum X: -PI * R
Minimum Y: -PI * R
Width: 2 * PI * R
Height: 2 * PI * R
R = 6378137 map units
This huge extent covers all the projections I can think of. Notice that each tile has a well-known extent which is implicit in its indices (z, x, y). In most cases, the map unit will be the meter. For example, in UTM the absolute value of both X and Y are always much smaller than PI * R, so there will be no problem there. If the map unit is the geodetic degree, we only need to go deep enough until the extent of the tiles is inside the interval [-180, 180].
The interesting z levels for a large country like China will be 0 to 18 if the projection is Spherical Mercator, but if that map of China is in EPSG:4326, interesting levels will be much deeper, perhaps between 14 and 32.
Why using a polygon for the extent?
By reading that polygon at the start, the application will have precise data about when it is necessary to search for tiles within the pyramid. If the current view is fully outside that polygon, the application simply skips this layer. This is much better than trying to draw the layer when the view intersects the bounding box of the tile pyramid.
What about the space needed to store that pyramid?
In quadtree pyramids, the deepest level represents about 75% of the total number of tiles. This means that the space needed to store the pyramid is only about 33% larger than that need to store the original raster (converted to JPG, PNG, etc.). I have repeated my first example using JPG (standard compression level) instead of PNG and I get these results:
Original ECW raster: 19 MB (1 file, 4355 x 5064 pixels)
JPG tiles pyramid (levels 0-18): 7.2 MB (374 files, 3840 x 4352 pixels in level 18)
JPG tiles pyramid (levels 0-19): 23.6 MB (1366 files, 7424 x 8704 pixels in level 19)
Obviously, tiles in level 19 have a slight mosaic effect because they have more pixels that the original ECW image. Unlike level 19, level 18 is losing some information.
Pros and cons of the proposed tile pyramid format.
- Avoids portability issues (you don’t need the raster libraries for the traditional formats, often written in C).
- Faster rendering: you don’t have to decompress anything, simply find out which tiles you need and paste them.
- Allows flexible extent.
- Needs some more space to be stored, compared to ECW.
- It can only be used with discrete zoom levels, of course, though this is very common on mobile applications.
- Needs some pre-processing on your desktop PC.
- If the pyramid is very large, it can take some time to copy it to the device.
All in all, I believe tile pyramids are a very good alternative to the most popular GIS raster formats when using mobile devices. Please let me know if I forgot some important con.