Gdal return the same data for all when area is too small

[stef]

We are having a big problem with Gdal when extracting data from a grib file (grib 1 or 2).

The problem is that Gdal returns a matrix with all same values when the specified area is too small. (small: when the Grib file's resolution is 0.5 degrees we must specify a zone bigger than 7.6 degrees, to have a matrix at least 15x15).

So my questions are : Why do Gdal returns the same data for the whole matrix ? And is there a ways to fix it ?

Thanks in advance, Stef

[warmerdam]

Stef,

Please supply a data file, and a minimal command / script / program that demonstrates the problem you are seeing. The easiest would be a gdal_translate command.

This is not an expected problem, and I don't recall any previous mention similar.

It would also be helpful to be specific about the version of GDAL/OGR and the platform.

[stef]

Correct file with wich Gdal return errors

[stef]

Hello Warmerdam, Thanks for the quick response.

So... as you may have seen I added the file which we are having problems (Gdal_bug_GFS.grb2).

The problem occurs when reading the raster bands. All the results are (almost) the same but they should not. Here is the code we use to get the data :

getUValues() {

const int xOff = 0; const int yOff = 0; int xSize = uBand.XSize; int ySize = uBand.YSize; uValues = new float[uBand.XSize * uBand.YSize]; int buf_xSize = uBand.XSize; int buf_ySize = uBand.YSize; const int pixelSpace = 0; const int lineSpace = 0; CPLErr error = uBand.ReadRaster(xOff, yOff, xSize, ySize, uValues, buf_xSize, buf_ySize, pixelSpace, lineSpace);

}

And here are the results :

value[0] : 4,794999 value[1] : 4,794999 value[2] : 4,798905 value[3] : 4,798905 value[4] : 4,794999 value[5] : 4,798905 value[6] : 4,794999 value[7] : 4,794999 value[8] : 4,787187 value[9] : 4,787187

Technical infos now :

Platform : Windows 7 Language : C# Gdal version : GDAL 1.8.0, released 2011/01/12

I hope you have everything you need to understand our problem and maybe find a solution to it.

Have a nice day. Stef

[warmerdam]

Stef,

You have not made it clear what band(s) you are operating on nor what xsize and ysize are. I tried a default translation of this 16x12 file and the result seemed reasonable. I then extracted just the top left 5x5 pixel area with gdal_translate and the results matched the subarea of the original and had reasonably varying values.

I did notice that the JP2KAK driver was invoked indicating that this is a JPEG2000 GRIB file. What JPEG2000 driver(s) have you built into your GDAL? Do you know which of them is being used? I suspect you are really seeing a problem with the jpeg2000 integration with the GRIB driver.

[stef]

Hello again Warmerdam,

Sorry for not being clear enough...

Well as you said the file is in fact correct (16x12) and the problem does not come from incorrect data but due to the Jpeg2000 compressor/decompressor.

We converted the file into grib1 format and the results are correct. Now we must find why the Jpeg2000 return always the same values...

The code of the Jpeg intregation is in Openjpeg I think... and the version is : openjpegv2\vc10 (2.10).

so... the new question is: Do you know if there's another decoder for Jpeg file that can be used with Gdal or maybe a newer version that may fix our problem ???

Thank you and have a nice day. Stef

[warmerdam]

Stef,

I did my testing using the JP2KAK JPEG2000 driver without any problems. I do not personally use the openjpeg driver so I don't know what problems it might have.

Unfortunately the Kakadu library on which the JP2KAK driver is build is not open source and not readily available to most people without paying money. You might want to try the JP2MRSID driver based on the MrSID SDK which while not open source is at least available for free for reading. It is based on a version of Kakadu and should be pretty reliable.