[SoC] SoC GDAL2Tiles: Status Report

[Klokan Petr Přidal]

Hi,

My SoC project description: http://trac.osgeo.org/gdal/wiki/SoCGDAL2Tiles

There are things we (gdal-dev) need to decide:

1) Clearly define the role of GDAL2Tiles.
The functionality is overlaying with gdal_retile.py utility.
In my opinion gdal2tiles should be more gdal2webtiles ;-) -
so it should concentrate more on TMS and Google Maps tiles
(Spherical Mercator tiles), generation of a web viewer and KML
SuperOverlay for Google Earth.

Is there a need for generation tiles in formats other then PNG/JPEG
with tile type of bands other then RGB(A) 8-bit?
What about functionality like generation shape file tileindex (for
MapServer) or world files for produced tiles?
The tile size is in the world of web tiles mostly fixed on 256x256
(just iPhone needs smaller version 128x128, and NASA WorldWind has
512x512). I guess size of tiles should be variable (now GDAL2Tiles
uses fixed 256).

Utility gdal_retile implements cutting into tiles as well, where is
the border between those two utilities?

2) How to improve quality of rendering - scale algorithm is now nearest
neighbour because GDAL2Tiles utilize GDAL's ReadRaster function, which
should be fastest.
Either I will query from GDAL bigger region with nearest
algorithm and then downscale it inside of the NumPy Array, or I will
switch to warping API (I will need that anyway for warping between map
projections).

Does it make sense to implement the scale down in memory - because of
speed, or I should not bother
with that and simply use warping api, same as gdal_retile do? FrankW?

3) I would like to have support for possibly all input data in
gdal2tiles, it means to include for example functionality from pct2rgb.py into
GDAL2TIles (people are complaing and reporting that as a bug).
Same with the conversion from 16-bit and 1-bit bands into 8-bit.

4) Improvement on the speed of gdal2tiles - I thought about generating
metatiles - something like 5 tiles with one request - in the row
probably - to improve the speed on sequential-only drivers.
JPEG is now horribly slow for example, any tips how to make GDAL2Tiles faster?

5) I would like to see GDAL2TIles be able to warp the tiles -
from different projections as well to remove the need to pre-process
temporary file with gdalwarp.

But first  I will start to implement algorithm generating TMS global
profile tiles from rasters in
EPSG:900913 and EPSG:4326.

Here is the list of tasks I did on SoC project (I was concentrated
more on the OpenLayers part of my project so far):

- I have now an account in OpenLayers trac/svn as well as private SVN sendbox.

- (I submitted an OpenLayers patch for Zoomify
#http://trac.openlayers.org/ticket/1285 - but I still have to work on
it) - this is very close to TMS modification driver I promised for
SoC.

- I rewrote a perl script of from USNaviguide
(http://www.usnaviguide.com/google-tiles.htm) to python (to understand
the code behind Google Maps). I returns coordinates of all overlaying
tiles for any bounding box given in WGS84
longlat coordinates.
But I will practically not use it in GDAL2Tiles, as I need EPSG:900913
coordinates for
generation of the tiles. Look at:
http://crschmidt.net/~crschmidt/spherical_mercator.html

I would like to have algorithm to query raster in EPSG:900913 for
Spherical Mercator Tile generation ready for the first deadline on
July 7-14th.

Comments are welcome....

Klokan