I'd check both files *before* all the processing. Something like:
gdallocationinfo -l_srs EPSG:4326 gribFile -110 40
gdallocationinfo -l_srs EPSG:4326 tiffFile -110 40
That will tell narrow it down.
On 1/31/24 15:53, Furuya, Takahiro via gdal-dev wrote:
Hi gdal-dev, I am Takahiro, a student who is using gdal_translate.
I have an issue with gdal_translate and would like to ask a question.
I used gdal_translate to transform a NCEP GRIB file (downloadable from
https://data.eol.ucar.edu/cgi-bin/codiac/fgr_form/id=21.093
<https://data.eol.ucar.edu/cgi-bin/codiac/fgr_form/id=21.093>, or
attached to this email) to GeoTiff, and compare those 2 data formats.
The command I used is
>gdal_translate -of GTiff st4_pr.2017092016.01h st4_pr.2017092016.01h.tif
(The GRIB file I used was st4_pr.2017092016.01h, which can be downloaded
from the above link by specifying “Begin Date/Time” to
“20170920”/“15:00:00” and “End Date/Time” to “20170920”/“15:59:59”.)
Then I read the 2 data files in R and checked if the original value at a
certain grid cell in the GRIB file remained at the same grid cell in the
GeoTiff file, but the value was shifted by 6 rows (the value I checked
was 9.75 [mm/hour] that was stored in index [100,86] in the original
GRIB file, but it was shifted to [106,86] in the GeoTiff file).
You can see the Python script used for reading the original GRIB file
here: https://bpa.st/ZNOSI <https://bpa.st/ZNOSI>
The R script used for checking the tif-translated data:
https://bpa.st/WZLSY <https://bpa.st/WZLSY>
The version of gdal_translate I used is 3.0.2.
Is this a known issue of gdal_translate? Or is this issue not supposed
to happen (is this the mistake of my side?)?
Best regards,
Takahiro
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
