[Tilecache] Huge dateline gap

[Dane Springmeyer]

Roger,

Right, that doc is not on/at a wiki, but in several ways that doc is  
better than wiki text since it is in reStructured text format here:

http://svn.tilecache.org/trunk/tilecache/docs/README.txt

I've recently been converting Mapnik's few official docs in Subversion  
to that format (and plan to do a lot more) because then users can  
provide patches to a central document and from that various formats  
can get easily regenerated.

So, that just an idea for you - pull from trunk, edit the doc, and  
then submit a patch.

Dane




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

> Christopher,
>
> That seems to have fully cured the edge problems - both at the  
> dateline, as well as at the South extent. Thanks again for your help.
>
>  I have a suggestion.  Would it be possible to take the information  
> in the current http://tilecache.org/readme.html and place it in a  
> Wiki?  I believe there are probably enough of us using TileCache,  
> that we could probably contribute documentation to clarify and  
> promote its use.
>
> Regards,
>
> Roger
> --
>
> On Tue, Nov 18, 2008 at 4:21 PM, Roger André <randre at gmail.com> 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?
>
> 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/72967788/attachment.html