[gdal-dev] Creating modified copies of a file
Cole, Derek
dcole at integrity-apps.com
Wed Jul 6 12:39:20 EDT 2011
What is the proper way to set those creation options?
I have tried the following:
char* papszOptions[] = { "BLOCKXSIZE=1024", "BLOCKYSIZE=1024" };
poVRTDS = poVRTDriver->CreateCopy( "", poDataset, FALSE, papszOptions, MyTextProgress, message);
poBand = poVRTDS->GetRasterBand(1);
CPLAssert( poBand->GetRasterDataType() == GDT_Byte );
poBand->GetBlockSize( &nXBlockSize, &nYBlockSize );
the block size variables are both still set to 128 instead of 1024, which is the block size of my input file.
Thanks
Derek
________________________________________
From: Even Rouault [even.rouault at mines-paris.org]
Sent: Tuesday, July 05, 2011 6:38 PM
To: gdal-dev at lists.osgeo.org
Cc: Cole, Derek
Subject: Re: [gdal-dev] Creating modified copies of a file
Le mercredi 06 juillet 2011 00:26:06, Cole, Derek a écrit :
> Just as an interesting side-note: I tried to do a CreateCopy on one of
> these files that was 7GB. Using CreateCopy() it took almost 2 hours. When
> I simply copied to file contents using a cp command (this is CentOS), the
> copy takes about a minute. I am not sure why that is so terribly slow in
> GDAL.
This is very well possible if the block dimensions of the source and target
are not compatible. You might want to play with the BLOCKXSIZE and BLOCKYSIZE
creation options.
Anyway, you cannot simply compare cp and CreateCopy(). CreateCopy() can do
much smarter things than just cp...
>
> Also, I experimented trying to insert a band into an already existing NITF
> file, but the software spits back an error message that the format does
> not support it.
Yes very few formats can support AddBand().
More information about the gdal-dev
mailing list