Re: [gdal-dev] gdal_translate shifted values

2024-02-01 Thread Laurențiu Nicola via gdal-dev 
Indeed, good catch, I exported both of them to a new file and it's obvious now:


Laurentiu

On Thu, Feb 1, 2024, at 15:22, Even Rouault wrote:
> Hi,
> 
> I don't think there's any problem regarding GDAL vs xarray. It is just a 
> difference of convention on how GDAL and xarray choose the origin of rasters. 
> GDAL selects the northern-west corner as the (0,0) image coordinate.
> 
> The line in GDAL that contains values 13.75 14.25 14.75 which are at line 80 
> for XArray is line 124   . And 80 + 124 + 1 = 205 , the dataset height
> 
> Displaying the GRIB dataset with QGIS (/GDAL) on top of OSM shows a plausible 
> georeferencing.
> 
> Even
> 
> Le 01/02/2024 à 13:57, Laurențiu Nicola via gdal-dev a écrit :
>> It's actually pretty easy to test:
>> 
>> import numpy as np
>> import xarray as xr
>> from osgeo import gdal
>> 
>> xarray_ds = xr.load_dataset("st4_pr.2017092016.01h", engine="cfgrib")
>> # GDAL uses  as NODATA
>> xarray_data = np.nan_to_num(xarray_ds.tp.data, nan=.0)
>> gdal_ds = gdal.Open("st4_pr.2017092016.01h")
>> gdal_data = gdal_ds.GetRasterBand(1).ReadAsArray()
>> 
>> >>> gdal_data[80]
>> array([.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   ,   40.5  ,   41.125,   41.75 ,   42.5  ,
>>  43.   ,   26.5  ,   26.875,   27.   ,   29.875,   49.875,
>>  50.375,   41.5  ,   41.375,0.   ,0.   ,0.   ,
>>   0.   ,0.   ,0.   ,0.   ,0.   ,0.   ,
>>   0.   ,0.   ,0.   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>   0.   ,0.   ,0.   ,0.   ,0.   ,0.   ,
>>   0.   ,0.   ,0.   ,0.   ,0.   ,0.   ,
>>   0.   ,0.   ,0.   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   ])
>> >>> xarray_data[80]
>> array([.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   ,   13.75 ,   14.25 ,   14.75 ,
>>  19.125,   32.5  ,   30.125,   27.125,   25.5  ,   22.25 ,
>>  22.375,   20.25 ,   18.375,   16.625,   15.25 , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .   , .   , .   ,
>>.   , .   , .   , .

Re: [gdal-dev] gdal_translate shifted values

2024-02-01 Thread Even Rouault via gdal-dev 

Hi,

I don't think there's any problem regarding GDAL vs xarray. It is just a 
difference of convention on how GDAL and xarray choose the origin of 
rasters. GDAL selects the northern-west corner as the (0,0) image 
coordinate.


The line in GDAL that contains values 13.75 14.25 14.75 which are at 
line 80 for XArray is line 124   . And 80 + 124 + 1 = 205 , the dataset 
height


Displaying the GRIB dataset with QGIS (/GDAL) on top of OSM shows a 
plausible georeferencing.


Even

Le 01/02/2024 à 13:57, Laurențiu Nicola via gdal-dev a écrit :

It's actually pretty easy to test:

import numpy as np
import xarray as xr
from osgeo import gdal

xarray_ds = xr.load_dataset("st4_pr.2017092016.01h", engine="cfgrib")
# GDAL uses  as NODATA
xarray_data = np.nan_to_num(xarray_ds.tp.data, nan=.0)
gdal_ds = gdal.Open("st4_pr.2017092016.01h")
gdal_data = gdal_ds.GetRasterBand(1).ReadAsArray()

>>> gdal_data[80]
array([. , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   ,   40.5  ,   41.125,   41.75 ,   42.5  ,
43.   ,   26.5  ,   26.875,   27.   ,   29.875,   49.875,
50.375,   41.5  ,   41.375,    0.   ,    0.   ,    0.   ,
0.   ,    0.   ,    0.   ,    0.   ,    0.   ,    0.   ,
0.   ,    0.   ,    0.   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
0.   ,    0.   ,    0.   ,    0.   ,    0.   ,    0.   ,
0.   ,    0.   ,    0.   ,    0.   ,    0.   ,    0.   ,
0.   ,    0.   ,    0.   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   ])
>>> xarray_data[80]
array([. , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   ,   13.75 ,   14.25 ,   14.75 ,
19.125,   32.5  ,   30.125,   27.125,   25.5  ,   22.25 ,
22.375,   20.25 ,   18.375,   16.625,   15.25 , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   , .   , .   ,
.   , .   , .   , .   ,

Re: [gdal-dev] gdal_translate shifted values

2024-02-01 Thread Laurențiu Nicola via gdal-dev 
It's actually pretty easy to test:

import numpy as np
import xarray as xr
from osgeo import gdal

xarray_ds = xr.load_dataset("st4_pr.2017092016.01h", engine="cfgrib")
# GDAL uses  as NODATA
xarray_data = np.nan_to_num(xarray_ds.tp.data, nan=.0)
gdal_ds = gdal.Open("st4_pr.2017092016.01h")
gdal_data = gdal_ds.GetRasterBand(1).ReadAsArray()

>>> gdal_data[80]
array([.   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   ,   40.5  ,   41.125,   41.75 ,   42.5  ,
 43.   ,   26.5  ,   26.875,   27.   ,   29.875,   49.875,
 50.375,   41.5  ,   41.375,0.   ,0.   ,0.   ,
  0.   ,0.   ,0.   ,0.   ,0.   ,0.   ,
  0.   ,0.   ,0.   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
  0.   ,0.   ,0.   ,0.   ,0.   ,0.   ,
  0.   ,0.   ,0.   ,0.   ,0.   ,0.   ,
  0.   ,0.   ,0.   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   ])
>>> xarray_data[80]
array([.   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   ,   13.75 ,   14.25 ,   14.75 ,
 19.125,   32.5  ,   30.125,   27.125,   25.5  ,   22.25 ,
 22.375,   20.25 ,   18.375,   16.625,   15.25 , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   , .   , .   , .   , .   , .   ,
   .   ], dtype=float32)

Re: [gdal-dev] gdal_translate shifted values

2024-02-01 Thread Roger Bivand via gdal-dev 
>From the R code snippet I see: "Surprisingly, the value 9.75 is shifted to 
>106, 86 = 105,85 in Python indexing", but R is 1-base and Python 0-base. In R:

> library(terra)
terra 1.7.71
> gdal()
[1] "3.8.3"
> a <- rast("attachment.obj")
> b <- rast("st4_pr.2017092016.01h.tif")
> a
class   : SpatRaster 
dimensions  : 205, 205, 1  (nrow, ncol, nlyr)
resolution  : 4762, 4762  (x, y)
extent  : 4940902, 5917112, -7210793, -6234583  (xmin, xmax, ymin, ymax)
coord. ref. : +proj=stere +lat_0=90 +lat_ts=60 +lon_0=-105 +x_0=0 +y_0=0 
+R=6367470 +units=m +no_defs 
source  : attachment.obj 
name: SFC (Ground or water surface); Total precipitation [kg/m^2] 
unit:  kg/m^2 
time: 2017-09-20 16:00:00 UTC 
> b
class   : SpatRaster 
dimensions  : 205, 205, 1  (nrow, ncol, nlyr)
resolution  : 4762, 4762  (x, y)
extent  : 4940902, 5917112, -7210793, -6234583  (xmin, xmax, ymin, ymax)
coord. ref. : +proj=stere +lat_0=90 +lat_ts=60 +lon_0=-105 +x_0=0 +y_0=0 
+R=6367470 +units=m +no_defs 
source  : st4_pr.2017092016.01h.tif 
name: 0[-] SFC (Ground or water surface) 
> all.equal(values(a), values(b))
[1] "Attributes: < Component \"dimnames\": Component 2: 1 string mismatch >"
> dimnames(values(a))
[[1]]
NULL

[[2]]
[1] "SFC (Ground or water surface); Total precipitation [kg/m^2]"

> dimnames(values(b))
[[1]]
NULL

[[2]]
[1] "0[-] SFC (Ground or water surface)"
> all.equal(values(a), values(b), check.attributes=FALSE)
[1] TRUE

Reading both into R shows that the input GRIB data and the GTiff data converted 
by gdal_translate are identical.

By the way, better to use the terra package directly, raster uses it indirectly.

Hope this clarifies,

Roger

--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_translate shifted values

2024-02-01 Thread Laurențiu Nicola via gdal-dev 
Hi Jukka,

If GDAL shuffled around the pixels in that file, you wouldn't be able to notice 
it by comparing the GRIB and the TIFF, because both would be shuffled.

My suggestion was to convert the GRIB to a NC or even CSV using xarray, then 
comparing the GDAL output against that.

Laurentiu

On Thu, Feb 1, 2024, at 13:18, Rahkonen Jukka via gdal-dev wrote:
> Hi,
>  
> I used the gdal_compare script https://gdal.org/programs/gdalcompare.html
> 
> gdalcompare  st4_pr.2017092016.01h st4_pr.2017092016.01h.tif
> and it reports three differences:
>  • Files differ at the binary level (normal, GRIB and tif are not the same)
>  • Difference in SRS (but they are alike, * IsSame() reports them as 
> equivalent.)
>  • Difference in Dataset metadata key count ( ['AREA_OR_POINT'] added)
> So if I read the report right the pixels in the files are identical. All I 
> can conclude is that gdal_compare and your R script are doing something in 
> different ways.
>  
> -Jukka Rahkonen-
>  
> *Lähettäjä:* gdal-dev  *Puolesta *Furuya, 
> Takahiro via gdal-dev
> *Lähetetty:* torstai 1. helmikuuta 2024 1.53
> *Vastaanottaja:* gdal-dev@lists.osgeo.org
> *Aihe:* [gdal-dev] gdal_translate shifted values
> 
>  
> 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, 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
> The R script used for checking the tif-translated data: 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

Re: [gdal-dev] gdal_translate shifted values

2024-02-01 Thread Rahkonen Jukka via gdal-dev 
Hi,

I used the gdal_compare script https://gdal.org/programs/gdalcompare.html

gdalcompare  st4_pr.2017092016.01h st4_pr.2017092016.01h.tif

and it reports three differences:

  *   Files differ at the binary level (normal, GRIB and tif are not the same)
  *   Difference in SRS (but they are alike, * IsSame() reports them as 
equivalent.)
  *   Difference in Dataset metadata key count ( ['AREA_OR_POINT'] added)

So if I read the report right the pixels in the files are identical. All I can 
conclude is that gdal_compare and your R script are doing something in 
different ways.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Furuya, 
Takahiro via gdal-dev
Lähetetty: torstai 1. helmikuuta 2024 1.53
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] gdal_translate shifted values

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, 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
The R script used for checking the tif-translated data: 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

Re: [gdal-dev] gdal_translate shifted values

2024-01-31 Thread Scott via gdal-dev 

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 
, 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 
The R script used for checking the tif-translated data: 
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

[gdal-dev] gdal_translate shifted values

2024-01-31 Thread Furuya, Takahiro via gdal-dev 
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, 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
The R script used for checking the tif-translated data: 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





st4_pr.2017092016.01h
Description: st4_pr.2017092016.01h
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev