Re: [gdal-dev] Problems writing big tiff image with RasterIO function
Jorge, On Mon, Oct 31, 2011 at 2:17 PM, Even Rouault wrote: > Selon Jorge Martin : >> I am using RasterIO function to write tiff files. The problem >> appears when the image size is aprox. 25000x25000 (500Mb), the last lines >> of the image are not correctly written. The last lines are written with 0 >> or 255 value. I have checked that if I only write a tiff file with the last >> lines of the image, this lines are correctly written. > You didn't mention your GDAL version. If it is not a recent one, you could try > upgrading and see if it works better. If you're seeing this behavior pre-1.8.1, it sounds similar to this bug, which has since been fixed: http://trac.osgeo.org/gdal/ticket/4090 -b -- Brian Claywell bcclayw...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Reproject Globcover
On Wed, Mar 16, 2011 at 5:12 PM, Monica Buescu wrote: > I pretend to reproject a known JRC product called GLOBCOVER to UTM WGS84 > (zone for France) using gdalwarp keeping spatial resolution (300m) and > null_values. Can anyone give me a suggestion on how to reproject it using > gdal? Try: gdalwarp -t_srs "EPSG:32631" -tr 300 300 -dstnodata 0 EPSG 32631 is WGS84 UTM zone 31N. See http://spatialreference.org/ref/epsg/32631/ -b -- Brian Claywell bcclayw...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Downsample with averaging?
On Mon, Feb 21, 2011 at 2:26 PM, Jay Jennings wrote: > [...] I’m looking for a > downsampling scheme that creates a result pixel by averaging all relevant > source pixels (I know, for 32:1 downsample, that means 1024 source pixels > for each result pixel !) with the hope of an output that is not “speckled” > or “grainy” insofar as possible. gdalwarp would probably give you the most control over the resampling algorithm: http://www.gdal.org/gdalwarp.html Look particularly at the -tr (target resolution, in georeferenced units) or -ts (target size, in pixels) options. For example, to produce a 32:1 thumbnail of a 44418x39108 GeoTIFF that I have laying around, $ gdalwarp -ts 1389 1223 -r bilinear input.tif output.tif You can experiment with the different resampling algorithms to find one you like (near, bilinear, cubic, cubicspline, lanczos). > gdaladdo -r average -ro X.tif 32 > > But that produces a surprising error message, namely: > > ERROR 4: `X.tif.ovr' does not exist in the file system, and is not > recognised as a supported dataset name. I tried gdaladdo with your arguments on the GeoTIFF I mentioned above (which is 3.4 GB) and it executed with no problems. Your error sounds like the *.tif.ovr file simply didn't get created; you might double-check that you have write permissions in the directory where your input file lives. I believe overviews are always written into the same directory as their source file, rather than your current working directory. -b -- Brian Claywell bcclayw...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MrSID mask band support
On Tue, Feb 15, 2011 at 1:19 PM, Even Rouault wrote: >> Barring that, since the MrSID driver reimplements the >> overview-related virtual functions to bypass the default overview >> manager, would there be any harm in initializing the overview manager >> when a MrSIDDataset object is created? > > Yes I think this should be harmless. But I'm not too sure of what will happen > if you try to get the overviews of the mask, or the mask of the overviews ... The basics of the patch were easy enough (23 lines): I initialize the overview manager near the end of MrSIDDataset::Open(), and implemented MrSIDDataset::IBuildOverviews() to simply print a warning, as Frank suggested. As to your last comment about masks of the overviews and overviews of the masks, Even, the behavior as it stands after this patch is that 1) the masks of the overviews are coming back as GMF_ALL_VALID, and 2) overviews of the masks are non-existent. I believe this is consistent with the current behavior of, e.g., adding a per-dataset mask to a GeoTIFF file that already has overviews. If that's sufficient, I'll create a ticket and submit the patch as-is -- otherwise, I'm open to suggestions. -b -- Brian Claywell bcclayw...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] MrSID mask band support
I'm attempting to use CreateMaskBand() on a MrSID dataset with GDAL 1.8.0 and receiving the error that "CreateMaskBand() is not supported on this dataset." I presume this is because mask band support was implemented using the GDALDefaultOverviews manager, and since MrSID is a multi-resolution format, the overview manager is never initialized. Is there a way to make mask bands work with MrSID datasets out of the box? Barring that, since the MrSID driver reimplements the overview-related virtual functions to bypass the default overview manager, would there be any harm in initializing the overview manager when a MrSIDDataset object is created? -b -- Brian Claywell bcclayw...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Warping with modified source geotransform
Our image-to-image coregistration process produces an affine transformation matrix that specifies the pixel-space transformation necessary to transform the image B to match image A. Since a geotransform is just an affine pixel-space transformation, the original image B geotransform can be combined with the coregistration transformation by matrix multiplication to yield a new image B geotransform. However, the new image B geotransform is not guaranteed to be north-up, so the image B (with its modified geotransform) needs to be warped into a north-up image, and to compute those parameters I've used the GDALSuggestedWarpOutput() function. But I've run into a bit of a roadblock. The GDALGenImgProjTransformer and GDALSuggestedWarpOutput() both read the source geotransform directly from the source dataset, but I want to inject the modified source geotransform as described in the above paragraph. Unfortunately, as best I can tell, it's near impossible to modify the source geotransform of a GDALGenImgProjTransformer, because the struct definition for GDALGenImgProjTransformInfo is hidden away inside alg/gdaltransformer.cpp, so one can't cast from void* to GDALGenImgProjTransformInfo* to get at the adfSrcGeoTransform member (at least without replicating the struct definition in my own code, but I'd really rather avoid breaking GDAL's encapsulation there :) ). Can anyone think of a way to accomplish this? Or is there a better way to do this that I haven't thought of? Thanks! -b -- Brian Claywell brian.clayw...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
