you're reading...
gvsig mobile, spherical mercator, tiling, wonthurt

Tile pyramids versus TIFF, ECW and such on mobile devices

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.

Proposed format

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
PNG
# Second line: tile width and height
256 256
# Third line: SRS code
EPSG:3857
# 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.

Conclusion

Pros and cons of the proposed tile pyramid format.

Pros:

  • 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.

Cons:

  • 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.

Advertisements

Discussion

5 thoughts on “Tile pyramids versus TIFF, ECW and such on mobile devices

  1. This is a very relevant proposal. This would in fact solve the present problem of lack of performance in today’s mobiles…

    Is gvSIG mobile going to implement this option? I think GDAL can create this kind of tiling scheme on the PC already…

    Duarte

    Posted by Duarte Carreira | 19/02/2010, 1:59 PM
  2. How is the ECW file “larger” than the tiles? The ECW is a highly optimized compressed format and should be at a minimum 15 times SMALLER than the tile scheme? Can you please “double check” the sizes of the imagery or check that your ECW file is compressed correctly? If it’s standard RGB imagery, it should be well over 50 times smaller?

    The advantage would be that you can store 50 times more imagery on the mobile devise which are not only “CPU” limited but disk space limited as well.

    Also, I don’t see any performance numbers or details about “how” ECW is being supported on the mobile platform? Can you please provide the details on this as well?

    ERDAS already has the Optimized Tile Deliver (OTD) Format which is a tile based format and is supported in the latest version of the SDK. It additionally has OTD builders in the ERDAS products.

    You can see the OTD Format in action at the http://iws.erdas.com or the New South Wales SIX Light Viewer in Australia at http://lite.maps.nsw.gov.au/

    Posted by Shawn Owston | 22/02/2010, 6:50 PM
  3. Hello, Shawn. Thanks for the feed-back.

    Perhaps I shouldn’t have said “you don’t need to decompress anything”. I meant “you don’t have to use external decompress libraries” (I assume JPG and PNG formats are well-known to any language). I thought it was obvious what I meant, since I’m talking about JPG and PNG tiles all the time. Anyway, sorry about that.

    As for the ECW compression, please have a look at this screenshot:

    What do you think? You think it’s a JPG-friendly image?

    You probably know very well the “one third rule”: if you build a quadtree pyramid on top of a raster, the total size (raster + pyramid) is one third bigger than the raster, so I still believe my main conclusions are right:

    – A JPG pyramid needs a bit more room than a ECW
    – It’s far more portable (JPG/PNG are well-known)
    – I have seen Java applications drawing ECW and drawing JPG tiles, and I believe the JPG tiles are faster. Do you honestly think the Ermapper library is as responsive as this app which uses tiles?

    http://www.youtube.com/juanlucasdominguez#p/u/1/kVc1dxxH0gg

    If you want, you can do this: randomly choose a lossless orthophoto from the internet (not from your website), compress it to ECW the best way you can and send me both the link to the original and the ECW, and I’ll write another post called ‘JPG tile pyramid vs. the best ECW Erdas can get’. I’ll choose the compression level for JPG to match the MAE (error) of your ECW. Fair enough?

    Regards,
    Juan Lucas

    Posted by gvsigmobileonopenmoko | 23/02/2010, 12:40 AM
  4. > randomly choose a lossless orthophoto…

    This proposal expires on Saturday, 27 Feb 2010. Thanks.

    Posted by gvsigmobileonopenmoko | 23/02/2010, 11:11 PM

Trackbacks/Pingbacks

  1. Pingback: GIS-Lab Blog» Архив блога » Новости вокруг 35 - 17/02/2010

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: