[Gdal-dev] TMS vs. GeoQuadTree

[Klokan Petr Přidal]

GDAL2Tiles:
To use or not to use TMS for on-line map publishing using static files?

There are several design differences in GeoQuadTree structure over TMS
structure:

Jordi, author of GeoQuadTree wrote me:

> Storage model
>
> In TMS a tile is addressed on a /layer/x/y.png basis (let's name it
> Cartesian), whereas GeoQuadTree stores the tiles on the filesystem
> hierarchically, based on the quadtree.
>
> How will GDAL2Tiles storage the tiles on the filesystem ?
>
>  If you store the tiles in a Cartesian fashion, then a client could access a
> tile with nothing more than a simple web server (the URL will include the
> exact position in the file system). In this approach, the number of image
> files depends on the size of the whole map. Any folder could store as many
> tiles as the number of tiles in the Y axis.
>
>  If you store the tiles in a hierarchical fashion (as GeoQuadTree do), then
> some layer of software (in the server) must translate the TMS notation in

My note: the same could be done in JavaScript on the client side too,
especially with optimization for global-mercator profile.

> the URL to the physical position in the filesystem. This process is quick
> and simple (I do it by means of a iteration, as many times as levels in the
> pyramid, but it can be optimized). In this approach, the number of image
> files is small and independent of the size of the whole map.
>
>  When I first thought of it, I was imaging huge maps, stored in any
> filesystem. I didn't want theoretical nor physical limitations. For
> instance, FAT32 only can manage 65534 files in a single folder. Let's
> imagine a map at 1:5000 scale. Let's consider a resolution of 0.5
> meters/pixel. Then a tile of 256x256 pixels would represent 128x128 meters.
> Thus at this scale, and considering only one file for each tile, the maximum
> storable map would be 8388 km in the Y axis. Maybe this is not a problem in
> many cases, but it's worse if you must store it in FAT16 (think of a small
> device with flash memory). FAT16 limits the number of files in a folder to
> 512.
>
>  The problem is worse with many file images per tile, as GeoQuadTree manages
> multiband.
>
>
> Tile format
>
>  GeoQuadTree version 0.9.0 only supported PNG as the format for tiles.
>
>  Some people (Frank Warmerdam amongst them) requested support for other
> formats.
>
>  GeoQuadTree 1.0.0 supports TIFF and JPEG as well as PNG as tile image
> formats.
>
>
> Multiband
>
> Will GDAL2Tiles support only RGB images ?
>
>  GeoQuadTree version 0.9.0 only supported RGB images, but someonerequested
> multiband support.
>
>  GeoQuadTree version 1.0.0 supports unlimited bands:
>
>  In the case of PNG format for tiles, a grey-valued PNG image is stored for
> each band in any tile (1.png for the first band, 2.png for the second band,
> etc). If the number of bands is 3, then any tile can be stored as 3
> gray-valued PNG images, or by means of a sole RGBA image ( 1.png).
>
>  In the case of TIFF format for tiles, a unique TIFF image is stored for all
> bands (1.tif), as TIFF format support multiband images.
>
>  In the case of JPEG format for tiles, a JPEG file is stored for each band
> in any tile (1.jpg for the first band, 2.jpg for the second band, etc.)
>
>
> Nodata values
>
>  GeoQuadTree 0.9.0 used the alpha channel in the PNG format to store the
> nodata values (0 indicated nodata, 255 indicated data).
>
>  GeoQuadTree 1.0.0 stores the nodata values with different approaches:
>
>  In the case of PNG format for tiles, the alpha channel is used for
> representing nodata values (0 indicates nodata, 255 or 65535 indicates
> data).
>
>  As Frank Warmerdam noted in the GDAL-dev mail list, with JPEG using a color
> as nodata it is not suitable. So I decided to use an associated PNG to store
> the nodata values. If the PNG is not present, then all pixels are considered
> data values. If the image tile file is not present, then all pixels are
> considered nodata values. If both the image file and nodata PNG file are
> present, then the values in the nodata PNG indicate if each pixel is data or
> nodata.
>
>  In the case of TIFF or JPEG format for tiles, a PNG file is associated with
> the tile, storing the data and nodata values. For instance, for a tile,
> there are 1.tif and 1.png . The first stores the image pixel values, and the
> second stores the nodata values.
> Best wishes,
>
> Jordi

Geo Quad Tree
-------------

Great features of GQT which I like:

- One map (including one!! metadata file and in the future multibands
tiles) is stored in one directory
- It is 100% file-format (especially 1.0 version) comparable to other
formats supported by GDAL, so one raster tiff source could be
converted into one tile format.
- There are already existing tools for process this format and
read-only driver for GDAL, now available under suitable license
- Conversion between tile formats could be done just by rename of tile
files and generating another metadata, so easy export into TMS
structure is still possible.

Disadvantages of GQT from my point of view:

- Not a label of OSGeo standard like TMS have
- A bit more complicated generation of tile url on client side, but
possible in JavaScript
- No viewer support this structure directly as I know, on the other
side QuadTree-based tile structure is used in Microsoft VirtualEarth
(tiles produced by tool MSR MapCruncher for example).

Tile Map Service
----------------

I have realized that TMS specification doesn't fit me because:

- TMS tile structure is not very well designed for simple hosting of
tiles on a webserver as static files. As I have seen only
global-mercator profile was practically used and then no metadata were
generated at all (or clients were not using them - OpenLayers,
WorldKit).
- Metadata like TileMap Resource XML have url of directory, how to
serve this as static file?
- Definition of standard is not well structured, there should be
section for simple static hosting (just tiles in global-geodetic,
without or with simple metadata) and definition of XML files which
serve list of available maps. A man should choose in my opinion if to
support whole TMS standard, eg. serve listing Metadata or host just
one map in some directory.
I see that TMS is mostly used by scripts, not as static files, but
anyway it should be designed to support this in my opinion.

on the other side, it's a standard supported by OSGeo, it has
easy-for-client tile naming structure....

Any comments are welcome... I hope you will not crucify me ;-)

Klokan