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é <[email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
