<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 18, 2008, at 4:21 PM, Roger André wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Christopher,<br><br>Thanks for the advice, I'll give that (0,10) a shot.<br><br>Any chance you can send me the link to, or the full-text of the conversation between Frank and Klokan?<br><br></blockquote><div><br></div><div> </div><div>klokan joined the chat room.</div><div>[08:02am] gdaltrac: Ticket #2683 (enhancement updated): MrSID as an external plugin, <a href="http://trac.osgeo.org/gdal/ticket/2683#comment">http://trac.osgeo.org/gdal/ticket/2683#comment</a>:2</div><div>[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</div><div>[08:12am] wohnout joined the chat room.</div><div>[08:12am] FrankW: But where does this end?</div><div>[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.</div><div>[08:13am] FrankW: Do we produce source packages for every format in case people want it as a plugin?</div><div>[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.</div><div>[08:15am] crschmidt: Where "Free" is "meets the OSD"</div><div>[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.</div><div>[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?</div><div>[08:17am] FrankW: So by that logic, only a few plugins would need this special treatment.</div><div>[08:17am] crschmidt: Right.</div><div>[08:17am] gdaltrac: Ticket #2683 (enhancement updated): MrSID as an external plugin, <a href="http://trac.osgeo.org/gdal/ticket/2683#comment">http://trac.osgeo.org/gdal/ticket/2683#comment</a>:3</div><div>[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.</div><div>[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</div><div>[08:18am] FrankW: ) then it isn't so bad.</div><div>[08:20am] crschmidt: #2385 is the ECW work, I believe</div><div>[08:20am] gdaltrac: Ticket #2385: ECW as an external plugin, <a href="http://trac.osgeo.org/gdal/ticket/2385">http://trac.osgeo.org/gdal/ticket/2385</a></div><div>[08:22am] markusN joined the chat room.</div><div>[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).</div><div>[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)...</div><div>[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</div><div>[08:37am] chippy left the chat room. (Remote closed the connection)</div><div>[08:38am] klokan: But it cut away New Zealand.. why? The input is -180,-90,180,90 in EPSG:4326.</div><div>[08:38am] FrankW: Can you show me what you mean by cut-away new zealand?</div><div>[08:39am] markusN: hi FrankW - thanks for the netCDF hack</div><div>[08:39am] markusN: I have invested some time to get the Geotransform nicer, looks good now!</div><div>[08:39am] FrankW: good, I presume there were some precision issues?</div><div>[08:40am] chippy joined the chat room.</div><div>[08:40am] klokan: FrankW: <a href="http://klokan.mzk.cz/~klokan/small_world.google.tif">http://klokan.mzk.cz/~klokan/small_world.google.tif</a></div><div>[08:41am] klokan: It is this file: <a href="http://download.osgeo.org/gdal/data/gtiff/small_world.tif">http://download.osgeo.org/gdal/data/gtiff/small_world.tif</a> projected to EPSG:900913.</div><div>[08:42am] FrankW: klokan: Try adding "-wo SOURCE_EXTRA=120" to your gdalwarp commandline without the quotes</div><div>[08:44am] markusN: FrankW: it looked like shifted for 1/2 pixel</div><div>[08:45am] klokan: FrankW: Then the result is correct...</div><div>[08:45am] klokan: but I can't pass such parameter to python.AutoCreateWarpedVRT, can I?</div><div>[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...</div><div>[08:52am] FrankW: I see there is no way to pass this through the swig bindings for autocreatewarpedvrt.</div><div>[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.</div><div>[08:53am] FrankW: You could, at least in theory, manipulate the VRT produced by AutoCreateWarpedVRT() to introduce the parameter.</div><div>[08:53am] klokan: I need also -dstalpha equivalent in VRT...</div><div>[08:53am] klokan: You mean save the file to disk and read it again and change the XML?</div><div>[08:53am] FrankW: yes, exactly.</div><div>[08:54am] klokan: What is the rule for adding SOURCE_EXTRA=120? When is it necessary to use it?</div><div>[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.</div><div>[08:55am] FrankW: But points right on the international date line might transform two different ways.</div><div>[08:55am] FrankW: so the region selector is missing the last swath of data.</div><div>[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.</div><div>[08:56am] FrankW: There is some discussion of it here: <a href="http://www.gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e08">http://www.gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e08</a></div><div>[08:57am] klokan: OK. Thanks</div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote type="cite">Roger<br>--<br><br><div class="gmail_quote"> On Tue, Nov 18, 2008 at 4:17 PM, Christopher Schmidt <span dir="ltr"><<a href="mailto:crschmidt@metacarta.com">crschmidt@metacarta.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">On Tue, Nov 18, 2008 at 04:07:19PM -0800, Roger André wrote:<br> > It's been pointed out that I didn't include a great deal of information<br> > about my setup. I doubt it will matter much, but here goes:<br> ><br> > I am using TileCache to read a large (14400x7200) raster with global<br> > extents. The raster projection is in lat/lon WGS84. TileCache is set to<br> > read this data via a MapServerLayer layer type, with settings that match the<br> > example in the out-of-the-box tilecache.cfg (metaTile=true, metaSize=5,5,<br> > metaBuffer=10).<br> <br> </div>set metaBuffer:0,10 and you may see your edge defects disappear to some<br> extent.<br> <br> Probably something like this is the problem:<br> <br> 11:55 < FrankW> The problem is that GDAL transforms the destination area<br> back to the source coordinate system by sampling a grid of points over<br> the region.<br> 11:55 < FrankW> But points right on the international date line might<br> transform two different ways.<br> 11:55 < FrankW> so the region selector is missing the last swath of<br> data.<br> <br> <br> In GDAL-land, you can use:<br> <br> 11:42 < FrankW> klokan: Try adding "-wo SOURCE_EXTRA=120" to your<br> gdalwarp commandline without the quotes<br> <br> <br> But I don't know how to use that through MapServer.<br> <div class="Ih2E3d"><br> > I am using the following package versions in my stack, and they have all<br> > been built from source:<br> ><br> > gdal-1.5.2<br> > mapserver-5.2.0<br> > proj-4.6.1<br> > proj-datumgrid-1.4<br> > tilecache-2.04<br> > --<br> ><br> ><br> ><br> > On Tue, Nov 18, 2008 at 3:17 PM, Roger André <<a href="mailto:randre@gmail.com">randre@gmail.com</a>> wrote:<br> ><br> > > Ok, so now that I've gotten meta-tiling with edge buffering to work, I seem<br> > > to be able to better control the missing pixel rows that were causing<br> > > horizontal stripes in my Google Map tiles. Only now I have a huge gap at<br> > > the international date line. I also have a band of missing data at the<br> > > extreme South edge of my tiles when I am past Zoom Level 5. I can probably<br> > > live with that, but since my data set is global, I find it interesting that<br> > > it's getting cut off, and only on the South side.<br> > ><br> > > Anyone seen this before?<br> > > --<br> > ><br> <br> </div>> _______________________________________________<br> > Tilecache mailing list<br> > <a href="mailto:Tilecache@openlayers.org">Tilecache@openlayers.org</a><br> > <a href="http://openlayers.org/mailman/listinfo/tilecache" target="_blank">http://openlayers.org/mailman/listinfo/tilecache</a><br> <font color="#888888"><br> <br> --<br> Christopher Schmidt<br> MetaCarta<br> </font></blockquote></div><br> _______________________________________________<br>Tilecache mailing list<br><a href="mailto:Tilecache@openlayers.org">Tilecache@openlayers.org</a><br>http://openlayers.org/mailman/listinfo/tilecache<br></blockquote></div><br></body></html>