>Folks,
>I would note that large -wm values can be very counter productive when
>used in combination with SKIP_NOSOURCE. The problem is that the larger
>the chunk size, you run into the chance that a large window will intersect
>a small amount of data and the whole window ends up being processed
Hello.
Is there no gap or noises in image data generated by this
method?
Regards.
--- doug_newc...@fws.gov wrote:
>
>
>
>
> >Hi Doug,
>
> >I finally tried your parameters and they did work
> fine for me also. I
> >had something like hundred geotiffs, 400 MB each,
> and I was pushing
doug_newc...@fws.gov wrote:
>Hi Doug,
>I finally tried your parameters and they did work fine for me also. I
>had something like hundred geotiffs, 400 MB each, and I was pushing
>them to bigtiff mosaic. I tried first with your *.tif selection and then
>again by using a virtual raster fil
>Hi Doug,
>I finally tried your parameters and they did work fine for me also. I
>had something like hundred geotiffs, 400 MB each, and I was pushing
>them to bigtiff mosaic. I tried first with your *.tif selection and then
>again by using a virtual raster file as source, created from Mapser
> fws.gov> writes:
>
> Hi Folks,Here's the gdal command (gdal 1.6.2) I used to merge ~3500 1
meter NAIP
> quarter quads (uncompressed geotiff TIFF) in 3 UTM projections into
one Bigtiff Image
> in the USGS Albers projection. It took about 15 hours ( on a 3 year
old Intel Core2
> Duo 64 bit Cent
s@ cc
lists.osgeo.org
Frank Warmerdam pobox.com> writes:
> Shaun Kolomeitz wrote:
> > could push beyond 1GB/s. Currently to process (mosaic) an 80GB image it
> > takes several days to complete. This is also on 32bit hardware, and I
>
> Shaun,
>
> I suspect that there is a gross issue with how the warping is being d
