GDAL2Tiles - Utility for easy tile-based publishing of raster maps and KML generation

gdal2tiles.py utility

Howard,

Could you integrate these updates?

docs/gdal_utilities.dox patch

Hi,
there are a few bugs in the script.

• There are a few places where the tileformat (.png) is hardcoded.
• The -nokml option has no effect. My patch fixes this, but klokan should have another look at the lines 704-715, there is some redundancy (forcekml).
• There is a huge performance brake for large source images (except for tiled TIFFs). The column-wise generation of the tiles is suboptimal, to say the least. I switched the x- and y-loop and got a performance boost of factor 6 for the first zoom level.

New stable 2.5 Openlayers is out now. Unfortunately it broke the GDAL2Tiles generated openlayers.html, because it is not back-compatible for binding TMS locally.

Fast solution is add 2.4 to the URL including OpenLayers?.js in openlayers.html:

<script src="http://www.openlayers.org/api/2.4/OpenLayers.js" type="text/javascript"></script>

Openlayers 2.5 already contains patch http://trac.openlayers.org/ticket/1023, created during FOSS4G code sprint in Victoria. It allows stable binding in new versions of GDAL2Tiles. I am going to work on it.

olt: thanks for the performance patch. PNG was hardcoded, I will check your patch. JPEG doesn't support transparency, and for fixed tile size (standard TMS) you can't create KML and HTML viewer tiles without nodata border for maps with width and height not modulo 256. Should the nodata be white or black for JPEG tiles? I prefer white (255), default is black (0), html viewer background is white. You will see the borders in Google Earth and it looks ugly. Best will be to have top and right tiles in PNG and rest in JPEG if you choose JPEG, but it is not nice solution and it is harder to implement on client side. So I decided before to support only PNG. Do we really would like to have JPEG tiles?

Do we really would like to have JPEG tiles?

PNG makes sense if you use it for Google Earth overlays or OpenLayers?. But gdal2tile can be a more general tool. I use it to split large TIFFs without any OpenLayers? or KML.*

Should the nodata be white or black for JPEG tiles?

The nodata value should be selectable. White is ok for html viewer, but otherwise black is "standard" (e.g. when you reproject in gdal).

* I added WorldFile? output, separated the tileformat from tiledrivername ('tiff' vs. 'GTIFF') and added support for custom gdal driver options. I can clean that up and make a patch, if someone is interested.

Re-assigning to Petr. See #1815 for more details about why.

The patch supplied by olt is commited (thank you again olt).

gdal2tiles.py r13208 should be ready for GDAL 1.5. All open tickets related to gdal2tiles were closed. I tested the tool with NG python binding (numpy and Numeric problem fixed). Now there is a support for new OpenLayer? TMS viewer, which comes with version 2.5 of OL and was prepared on FOSS4G Canada code sprint. GDAL2Tiles script runs with trunk version of GDAL as well as with FWTools 2.0 under both Linux and Windows. Documentation was commited and is already available at the website, there is an enhanced version in gdal wiki too.

I am closing this ticket.

olt: Please could you open a new ticket for WorldFile? generation and your suggested changes? The patch would be very nice, I think people are interested and it would move gdal2tiles forward.

Replying to klokan:

olt: Please could you open a new ticket for WorldFile? generation and your suggested changes? The patch would be very nice, I think people are interested and it would move gdal2tiles forward.

Opened two tickets. One for jpg and tiff support #2052 and one for world files #2053.