[gdal-dev] Re: gdal2tiles dateline gap

[Klokan Petr Přidal]

Jeff and others,

>> Gdal2tiles output  is chopping off New Zealand from a global data set...the
>> input spherical mercator global image has New Zealand intact. Did you
>> discover a solution after posting to 'gdal.dev' nine weeks ago?

In such case just call gdal2tiles with specified srs for Shperical Mercator:

gdal2tiles --s_srs epsg:900913 yourinput.tif

This way gdal2tiles will not do the reprojection but it just creates
tiles from your input as it is.

Chopping off some areas happens when gdal2tiles is doing the internal
reprojection of the global dataset himself, because of the default
behavior of AutoCreateWarpedVRT in GDAL - this also happens when you
call gdalwarp from command line without extra parameters and doing
reprojection on global datasets.

The whole problem and it's temporary solution step by step is described here:
http://code.google.com/p/maptiler/issues/detail?id=6

I am working on a patch for gdal2tiles, which will fix this global
reprojection chopping problem as well as problem with pixel inprecise
warping coming out of gdal2tiles for tiles in deep zoom levels.

Because gdal does not expose much functionality to python I have to do
that by editing of the warping VRT (XML) in the postprocessing step,
after AutoCreateWarpedVRT is called...

Klokan

On Mon, Mar 16, 2009 at 10:16 PM, Roger André <randre at gmail.com> wrote:
> Hi Jeff,
>
> Adding list, just in case there is additional input on this.
>
> Yes, but the solution I found may not be applicable to your use-case.
> I needed to create Google Map tiles in spherical mercator projection,
> not Google Earth KML, so I was able to use TileCache with MapServer to
> generate them.  I found that I had more flexibility using that
> solution, than I did using the gdal2tiles tool.
>
> I should also add that when I used input data that was already in
> sperical mercator projection, I was unable to get data all the way out
> to the edges of their defined extents.  You might try converting the
> input data to EPSG:4326 first, then see what you get out of
> gdal2tiles.  I believe it can handle the reprojection for you
> on-the-fly.
>
> Roger
> --
>
>>
>>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
http://blog.klokan.cz/
http://www.maptiler.org/
http://www.oldmapsonline.org/