[Tilecache] Huge dateline gap

Tue Nov 18 19:32:16 EST 2008

On Nov 18, 2008, at 4:21 PM, Roger André wrote:

> Hi Christopher,
>
> Thanks for the advice, I'll give that (0,10) a shot.
>
> Any chance you can send me the link to, or the full-text of the  
> conversation between Frank and Klokan?
>

klokan joined the chat room.
[08:02am] gdaltrac: Ticket #2683 (enhancement updated): MrSID as an  
external plugin, http://trac.osgeo.org/gdal/ticket/2683#comment:2
[08:08am] crschmidt: FrankW: I'll toss in my two cents that I would be  
very interested in having the ability to use the Debian-provided GDAL  
with a minimal set of steps to compile to support MrSID imagery
[08:12am] wohnout joined the chat room.
[08:12am] FrankW: But where does this end?
[08:13am] CIA-52: klokan * r15747 /trunk/gdal/swig/python/scripts/ 
gdal2tiles.py: Bugs in new gdal2tiles repaired: tilemapresource.xml is  
not correct, mercator and geodetic profiles generates minus tiles, PIL  
'antialias' is not running, yahoomapid not filled in OpenLayers  
template.
[08:13am] FrankW: Do we produce source packages for every format in  
case people want it as a plugin?
[08:15am] crschmidt: FrankW: well, my personal feeling is that it  
would probably be most helpful for plugins which require the support  
of external, non-free libraries.
[08:15am] crschmidt: Where "Free" is "meets the OSD"
[08:16am] crschmidt: But maybe even that is too much. I don't know  
enough about the code to say -- I just thought I'd offer an opinion.
[08:16am] FrankW: So part of what makes it special is that it is a  
format that could never be included by default in any of the linux  
distributions - is that right?
[08:17am] FrankW: So by that logic, only a few plugins would need this  
special treatment.
[08:17am] crschmidt: Right.
[08:17am] gdaltrac: Ticket #2683 (enhancement updated): MrSID as an  
external plugin, http://trac.osgeo.org/gdal/ticket/2683#comment:3
[08:17am] FrankW: We have a source release for the GRASS plugin and  
I've noticed it is not released with each version of GDAL and this  
causes much confusion amoung users.
[08:18am] FrankW: But at least if it were only a few (I get the  
impression the same work has been done for ecw by someone
[08:18am] FrankW: ) then it isn't so bad.
[08:20am] crschmidt: #2385 is the ECW work, I believe
[08:20am] gdaltrac: Ticket #2385: ECW as an external plugin, http://trac.osgeo.org/gdal/ticket/2385
[08:22am] markusN joined the chat room.
[08:30am] CIA-52: klokan * r15748 /trunk/gdal/swig/python/scripts/ 
gdal2tiles.py: GDAL2Tiles: "--resume" functionality: allows to  
continue in interupted tile generation, regenerates files which do not  
exist (usefull for metadata or overview only generation).
[08:36am] klokan: How can I generate whole world in one Google tile  
from EPSG:4326 dataset... I was trying to do that for small_world.tif  
(from gdal samples)...
[08:37am] klokan: Command like: dalwarp -t_srs epsg:900913 -te  
-20037508.34 -20037508.34 20037508.34 20037508.34 small_world.tif  
small_world.google.tif
[08:37am] chippy left the chat room. (Remote closed the connection)
[08:38am] klokan: But it cut away New Zealand.. why? The input is  
-180,-90,180,90 in EPSG:4326.
[08:38am] FrankW: Can you show me what you mean by cut-away new zealand?
[08:39am] markusN: hi FrankW - thanks for the netCDF hack
[08:39am] markusN: I have invested some time to get the Geotransform  
nicer, looks good now!
[08:39am] FrankW: good, I presume there were some precision issues?
[08:40am] chippy joined the chat room.
[08:40am] klokan: FrankW: http://klokan.mzk.cz/~klokan/small_world.google.tif
[08:41am] klokan: It is this file: http://download.osgeo.org/gdal/data/gtiff/small_world.tif 
  projected to EPSG:900913.
[08:42am] FrankW: klokan:  Try adding "-wo SOURCE_EXTRA=120" to your  
gdalwarp commandline without the quotes
[08:44am] markusN: FrankW: it looked like shifted for 1/2 pixel
[08:45am] klokan: FrankW: Then the result is correct...
[08:45am] klokan: but I can't pass such parameter to  
python.AutoCreateWarpedVRT, can I?
[08:49am] klokan: So in case somebody will report that as a bug I will  
tell them that they have to run gdalwarp -of vrt with -wo  
SOURCE_EXTRA=120 in advance, before passing dataset to gdal2tiles for  
tile generation...
[08:52am] FrankW: I see there is no way to pass this through the swig  
bindings for autocreatewarpedvrt.
[08:52am] FrankW: This boils down to the warp api being awfully  
complex to properly wrap for swig and our various compromises  
resulting in incomplete access.
[08:53am] FrankW: You could, at least in theory, manipulate the VRT  
produced by AutoCreateWarpedVRT() to introduce the parameter.
[08:53am] klokan: I need also -dstalpha equivalent in VRT...
[08:53am] klokan: You mean save the file to disk and read it again and  
change the XML?
[08:53am] FrankW: yes, exactly.
[08:54am] klokan: What is the rule for adding SOURCE_EXTRA=120? When  
is it necessary to use it?
[08:55am] FrankW: The problem is that GDAL transforms the destination  
area back to the source coordinate system by sampling a grid of points  
over the region.
[08:55am] FrankW: But points right on the international date line  
might transform two different ways.
[08:55am] FrankW: so the region selector is missing the last swath of  
data.
[08:55am] FrankW: The SOURCE_EXTRA is just forcing it to pull more  
data from the source image for it's working buffer than it thinks it  
needs.
[08:56am] FrankW: There is some discussion of it here: http://www.gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e08
[08:57am] klokan: OK. Thanks

> Roger
> --
>
> On Tue, Nov 18, 2008 at 4:17 PM, Christopher Schmidt <crschmidt at metacarta.com 
> > wrote:
> On Tue, Nov 18, 2008 at 04:07:19PM -0800, Roger André wrote:
> > It's been pointed out that I didn't include a great deal of  
> information
> > about my setup.  I doubt it will matter much, but here goes:
> >
> > I am using TileCache to read a large (14400x7200) raster with global
> > extents.  The raster projection is in lat/lon WGS84.  TileCache is  
> set to
> > read this data via a MapServerLayer layer type, with settings that  
> match the
> > example in the out-of-the-box tilecache.cfg (metaTile=true,  
> metaSize=5,5,
> > metaBuffer=10).
>
> set metaBuffer:0,10 and you may see your edge defects disappear to  
> some
> extent.
>
> Probably something like this is the problem:
>
> 11:55 < FrankW> The problem is that GDAL transforms the destination  
> area
> back to the source coordinate system by sampling a grid of points over
> the region.
> 11:55 < FrankW> But points right on the international date line might
> transform two different ways.
> 11:55 < FrankW> so the region selector is missing the last swath of
> data.
>
>
> In GDAL-land, you can use:
>
> 11:42 < FrankW> klokan:  Try adding "-wo SOURCE_EXTRA=120" to your
> gdalwarp commandline without the quotes
>
>
> But I don't know how to use that through MapServer.
>
> > I am using the following package versions in my stack, and they  
> have all
> > been built from source:
> >
> > gdal-1.5.2
> > mapserver-5.2.0
> > proj-4.6.1
> > proj-datumgrid-1.4
> > tilecache-2.04
> > --
> >
> >
> >
> > On Tue, Nov 18, 2008 at 3:17 PM, Roger André <randre at gmail.com>  
> wrote:
> >
> > > Ok, so now that I've gotten meta-tiling with edge buffering to  
> work, I seem
> > > to be able to better control the missing pixel rows that were  
> causing
> > > horizontal stripes in my Google Map tiles.  Only now I have a  
> huge gap at
> > > the international date line.  I also have a band of missing data  
> at the
> > > extreme South edge of my tiles when I am past Zoom Level 5.  I  
> can probably
> > > live with that, but since my data set is global, I find it  
> interesting that
> > > it's getting cut off, and only on the South side.
> > >
> > > Anyone seen this before?
> > > --
> > >
>
> > _______________________________________________
> > Tilecache mailing list
> > Tilecache at openlayers.org
> > http://openlayers.org/mailman/listinfo/tilecache
>
>
> --
> Christopher Schmidt
> MetaCarta
>
> _______________________________________________
> Tilecache mailing list
> Tilecache at openlayers.org
> http://openlayers.org/mailman/listinfo/tilecache

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/tilecache/attachments/20081118/5871e775/attachment.html