[Tilecache] Huge dateline gap

Tue Nov 18 19:34:07 EST 2008

Sweet, thanks.  Guess I'm going to have to start lurking.
--

On Tue, Nov 18, 2008 at 4:32 PM, Dane Springmeyer <blake at hailmail.net>wrote:

>
> 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<http://klokan.mzk.cz/%7Eklokan/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/1d738efa/attachment.html