[Tilecache] Huge dateline gap

Tue Nov 18 19:58:30 EST 2008

Roger,

I'm sure others will correct me where I'm mistaken, but I would do a  
read-only subversion checkout of the docs:

$ svn co http://svn.tilecache.org/trunk/tilecache/docs/ tilecache_docs
$ cd tilecache_docs

* Then make my edits...
* Then check my changes...

$ svn diff
Index: README.txt
===================================================================

--- README.txt	(revision 365)
+++ README.txt	(working copy)
@@ -16,6 +16,8 @@

  DESCRIPTION
  ===========
+TileCache Rocks!
+
  TileCache is a BSD licensed tile caching mechanism.  The goal is to  
make it
  easy to set up a WMS or TMS frontend to any backend data services  
you might be
  interested in, using a pluggable caching and rendering mechanism.

* Finally, create I'd create a diff file and email to the list

$ svn diff > danes_rockin_patch.diff


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

> Hi Dane,
>
> If that's an acceptable means of doing it, I'd be happy to make  
> edits that way.  How do I go about requesting repo access so that I  
> can edit it?
>
> R
> --
>
> On Tue, Nov 18, 2008 at 4:38 PM, Dane Springmeyer  
> <blake at hailmail.net> wrote:
> 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/220f0062/attachment.html
