[gdal-dev] gdal2tiles.py and dateline gap

[Klokan Petr Přidal]

Hi Roger,

the problem is related to the default behavior of GDAL warping core,
which sometimes does not have enough input pixels or has a problem to
calculate correct target extent.

What you can do is to warp your input data into EPSG:900913 by
gdalwarp utility before tiling by gdal2tiles utility.
GDAL2Tiles will not warp the input again, so you have all the warping
totally under your control in such case.

Typically you should use a command like:

gdalwarp -of vrt -t_srs epsg:900913 -wo SOURCE_EXTRA=120 input.tif output.vrt
gdal2tiles output.vrt

The trick is to use correct SOURCE_EXTRA value, which is documented here:
http://www.gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e08

I realized that for images which are going out of the bounds of
Spherical Meractor it is better to specify also the cropping  bounds,
for example:

gdalwarp -t_srs epsg:900913 -te -20037508.34 -20037508.34 20037508.34
20037508.34 -wo SOURCE_EXTRA=120 small_world.tif
small_world.google.tif

BTW For anybody interested in seeing the tile bounds of Spherical
Meracator Tiles (Google Maps, etc.) I created a simple mashup with the
documentation. Tile bounds appear when you click the map:
http://www.maptiler.org/google-maps-coordinates-tile-bounds-projection/

It would be nice to have an algorithm for calculating how many input
pixels are missing (so how big the SOURCE_EXTRA value should be) -
probably with help of Proj4/OGR.
I can then automatically add such calculated value to the internal
warping functionality of GDAL2Tiles (in the postprocessing of VRT file
which is coming from AutoCreateWarpedVRT function).

FrankW or anybody else: any tips?

More clean of course would be to have it correctly set by default in
the C++ warping core, so the gaps does not appear at all (it appears
also on the command line with gdalwarp utility). But I guess it is
quite problematic to make an general algorithm.
I have found a patch trying to solve this issue for some polar
projections: http://trac.osgeo.org/mapserver/ticket/2765.
Is there any progress in this direction?

Best regards

Klokan

P.S.
The discussion between me and Frank related to this is archived here:
http://openlayers.org/pipermail/tilecache/2008-November/001445.html

On Wed, Jan 7, 2009 at 12:33 AM, Roger André <randre at gmail.com> wrote:
> I've gotten the map tile output from gdal2tiles.py to work properly with
> Tilecache and the results look pretty good.  However, I'm seeing a fairly
> large gap in data at the international dateline.  I recall seeing some
> discussion about this between Frank and Klokan on the list previously, and
> recompiled gdal after editing gdal/alg/gdalwarpoperation.cpp and adding a
> larger size to the sampling edge buffer.  This doesn't seem to have helped
> though.
>
> Is it possible to create a global tileset with gdal2tiles.py without having
> a gap at the dateline?
>
> Thanks,
>
> Roger
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>