[gdal-dev] Creating modified copies of a file

[Even Rouault]

Le mercredi 06 juillet 2011 23:18:21, Cole, Derek a écrit :
> I have noticed that when attempting to do this, I am able to do a gdalinfo
> on the source and destination files (even if the destination file is not
> complete, it seems the header gets created, and gdalinfo recognizes teh
> file).
> 
> Is it possible that this is taking so long because my destination file has
> no geocoords or projection information? It seems like createcopy is not
> replicating all of the variables in the original and I am having to
> manually set some things, such as Block size, ABPP, etc etc. 

This is expected. When doing CreateCopy() the target driver has no idea what 
the source driver is, so he will not recognize ABPP. As far as block sizes are 
concerned, it is up to the user to decide if he wants to keep or change the 
block dimension of the source dataset.

I'm a bit surprised that CreateCopy() is *that* much slower than cp, but it is 
hard to know why without a hard work of profiling. It might be related to pixel 
or band interleaving, etc... There might cache trashing. You could perhaps run 
with CPL_DEBUG=ON and see if interesting info comes up.

> And the
> coordinates and projection information is blank in the new file. Is there
> perhaps some calculations being done to correct that issue, and thats why
> the copy is taking forever? 

No, not related at all.

> I thought based on the documentation
> CreateCopy() would clone the file's raster, as well as size, type,
> projection, geotransform, etc, but all of this is not showing up in the
> partially created file at least.

You cannot reliably trust gdalinfo on a file still being written. Depending on 
the driver some information might just be written at the end of the process. A 
quick look at the CreateCopy() implementation of the NITF driver suggests that 
this is indeed the case since the geotransform is set after the imagery.