[gdal-dev] Warping an image using GDALAutoCreateWarpedVRT() and other questions

[Adeel Raza]

Hi,

You're awesome Even. I suppose I will give the MEM driver a try as you 
suggested. Thanks so much. :)

Regards,
Adeel.

Even Rouault wrote:
> Le Thursday 09 July 2009 20:38:13 Adeel Raza, vous avez écrit :
>   
>> Hi,
>>
>> I'm using the "GTiff" driver and using it to create an empty file.
>> Afterwards I write data to the (one and only) rasterband using a float
>> array as the buffer (the GDALDataType I use for the GDALDataset is
>> GDT_Float32 - I believe that should be ok). Then I warp the image
>> using  the GDALAutoCreateWarpedVRT() function. I have noticed that after
>> the image is warped, the number of pixels are not the same as the
>> original TIFF image. Is this normal? I know this sounds like a stupid
>> question, but I need to be sure.
>>     
>
> Yes it is normal if you change projection. The shape and resolutions of the 
> output will not be the same as the input.
>
>   
>> Secondly I was also wondering how the GDALRasterBand::RasterIO()
>> function feeds data into the raster band. I make a function call to the
>> RasterIO function according to the following code:
>>
>>     GDALDriver *tifDriver;
>>     GDALDataset *srcDataset;
>>
>>     tifDriver = (GDALDriver *)GDALGetDriverByName("GTiff");
>>     assert(tifDriver != NULL);
>>     srcDataset = tifDriver->Create("srcDataset.tif", nCols, nRows, 1,
>> GDALDataType::GDT_Float32, NULL);
>>     assert(srcDataset != NULL);
>>
>>     srcDataset->GetRasterBand(1)->RasterIO(GF_Write, 0, 0, nCols, nRows,
>> realCellVals, nCols, nRows, GDALDataType::GDT_Float32, 0 , 0);
>>
>> Both nCols and nRows are unsigned shorts and realCellVals is defined as
>> "float *realCellVals = new float[nCols*nRows];". I have filled
>> realCellValls so that the row at the top of the raster image is the
>> first row and the row at the bottom of the raster image is the last row
>> in the array. Also columns indices increase from left to right. Will
>> this implementation work properly with the RasterIO() function or do I
>> need to arrange my array in another way? 
>>     
>
> I guess you could try and check yourself ;-) If I've understood your 
> description, this should work as you expect.
>
>   
>> The reason why this is critical 
>> is so that I can create a north up TIFF image, warp it to the desired
>> projection system, and get an affine geo transform of the warped north
>> up image so that GT[2] and GT[4] are 0 (GT is the returned affine geo
>> transform from the function - GDALDataset::GetGeoTransform()).
>>     
>
> GDALAutoCreateWarpedVRT() will return a dataset with such characteristics. (to 
> be exact, it won't necessary be exactly "north up", it depends on the 
> destination projection, but I play a bit on words)
>
>   
>> Lastly I initially tried the same approach using a virtual database and
>> creating it in memory using the GDALDriver::Create() function. I tried
>> using the GDALRasterBand::RasterIO() function on the database but I got
>> an error saying "writing to VRTWarpedRasterBands is not supported".
>>     
>
> A VRT file can be created (the XML description), and data can be read from it. 
> But writing pixels into it doesn't make any sense of course, so the error 
> message is logical.
>
>   
>> Therefore I had to use the tiff format to warp the image. Is there
>> anyway to bypass this so that I don't have to create a temporary tiff
>> file to warp my image?
>>     
>
> Yes, I see 2 possibilities : 
> * use the MEM driver instead of the GTiff driver to create an in-memory source 
> dataset (easiest way)
> * use the /vsimem virtual filesystem to creaty an in-memory GeoTIFF file
>
>   
>> Any help would be greatly appreciated. Thanks.
>>
>> Best Regards,
>> Adeel.
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>     
>
>
>
>