Re: [gdal-dev] gdalwarp's default nodata value

papszWarpOptions = CSLSetNameValue(papszWarpOptions, "INIT_DEST", "nan" ); than I get zeros again in place of the nodata. Works for me. You'll have to use your debugger I'm afraid For the rec, VS2010 and a quite recent trunk version. papszWarpOptions = CSLSetNameValue(papszWarpOp

Re: [gdal-dev] gdalwarp's default nodata value

Le Wednesday 12 May 2010 23:15:08 Joaquim Luis, vous avez écrit : > Even, > > Thanks, I understand it better now and made some advances but I'm still > facing some troubles. > > For example, if I do this > > papszWarpOptions = CSLSetNameValue(papszWarpOptions, "INIT_DEST", "300" ); > psWO->papszWar

Re: [gdal-dev] gdalwarp's default nodata value

Even, Thanks, I understand it better now and made some advances but I'm still facing some troubles. For example, if I do this papszWarpOptions = CSLSetNameValue(papszWarpOptions, "INIT_DEST", "300" ); psWO->papszWarpOptions = CSLDuplicate(papszWarpOptions); than it works fine. However, if I

Re: [gdal-dev] gdalwarp's default nodata value

Joaquim, I believe what you see is the expected behaviour. You must keep in mind that there are 2 notions : 1) nodata value --> setting it is no more than just setting a "tag" on the raster band. It doesn't change the pixel values by itself as Chaintanya explained 2) initialization of the pixel

Re: [gdal-dev] gdalwarp's default nodata value

On 12-05-2010 15:58, Chaitanya kumar CH wrote: Joaquim, GDALSetRasterNoDataValue() sets only the metadata. It doesn't actually change the nodata pixels. We need to process each pixel to do this. Or you could just create a VRT mentioning the source and vrt nodata values. Chaitanya, Thanks,

Re: [gdal-dev] gdalwarp's default nodata value

Joaquim, GDALSetRasterNoDataValue() sets only the metadata. It doesn't actually change the nodata pixels. We need to process each pixel to do this. Or you could just create a VRT mentioning the source and vrt nodata values. http://www.gdal.org/gdal_vrttut.html http://www.gdal.org/gdalbuildvrt.htm

Re: [gdal-dev] best way to compare in a numpy table the values of two images with different projection

Matthieu Rigal wrote: Hi folks, I am currently implementing a tool to allow band-to-band computations on array values out of 2 images with different projection and different resolution in python. The operation is quite complex, so I will summarize it here and below give the solution I am cur

Re: [gdal-dev] best way to compare in a numpy table the values of two images with different projection

Matthieu, Looks like you are finally reprojecting the image, perhaps to the projection of image B. Reprojection is costly. I suggest performing it on A instead of B. Let us know how it goes. On Wed, May 12, 2010 at 7:19 PM, Matthieu Rigal wrote: > Hi folks, > > I am currently implementing a too

[gdal-dev] best way to compare in a numpy table the values of two images with different projection

Hi folks, I am currently implementing a tool to allow band-to-band computations on array values out of 2 images with different projection and different resolution in python. The operation is quite complex, so I will summarize it here and below give the solution I am currently testing to see if

Re: [gdal-dev] gdalwarp's default nodata value

On 12-05-2010 05:55, Chaitanya kumar CH wrote: Joaquim, On Wed, May 12, 2010 at 5:07 AM, Joaquim Luis > wrote: Hi, Before filling a ticket I would like to ask here if this gdalwarp behavior is the intended one. When I convert a grid from geogs to UTM the