[OSGeo-Discuss] Observation when converting GeoTIFF to NetCDF using gdal_translate

Hendy Sumanto hsumanto at vpac.org
Wed Jul 27 01:32:16 PDT 2011


>>I am running into a similar issue, and it also seems to be related to the "South-Up" problems reported in that thread.

This is the previous thread which I was referring and might be related with my current post.

http://www.osgeo.org/pipermail/gdal-dev/2009-March/020005.html

Regards,

Hendy

----- Original Message -----
From: "Hendy Sumanto" <hsumanto at vpac.org>
To: discuss at lists.osgeo.org
Sent: Wednesday, 27 July, 2011 3:44:54 PM
Subject: [OSGeo-Discuss] Observation when converting GeoTIFF to NetCDF using	gdal_translate

Hi Roger, Frank and Everyone,

My name is Hendy from Australia.

I am running into a similar issue, and it also seems to be related to the "South-Up" problems reported in that thread.

I am converting a Geotiff into NetCDF and I can see the Origin has shifted because of the "South-Up" stuff.

I have tried the 1.6 till 1.8.1 versions of gdal_translate but still having the same issue.

If you don't mind could you please share with me your findings or your thoughts.

First, from my observation it seems gdalinfo produced different results especially with floating point numbers as you could see I have different floating point precision on gdalinfo on L71092086_08620110129_B50.TIF for my 64bit windows 7 machine and 64bit linux machine (debian squeeze) as shown in L71092086_08620110129_B50.gdalinfo versus L71092086_08620110129_B50_on_linux_amd64.gdalinfo

Second, if I do convertion from GeoTIFF -> NetCDF using gdal_translate:

gdal_translate -of netCDF L71092086_08620110129_B50.TIF L71092086_08620110129_B50-netCDF.nc
I get the same "South-Up" issue when looking at gdalinfo L71092086_08620110129_B50-netCDF.nc

Thus, when coordinates are in floating-point format, there might potentially be floating-point number conversion issue with gdal_translate as I observed below:

    The origin has shifted from

Origin = (281384.999999999941792,-4040684.999999999534339)

to

Origin = (281385.000000000000000,-4040680.000000000000000)

Thus shifting the corner coordinates from

Corner Coordinates:

Upper Left ( 281385.000,-4040685.000)

Lower Left ( 281385.000,-4254315.000)

Upper Right ( 525015.000,-4040685.000)

Lower Right ( 525015.000,-4254315.000)

Center ( 403200.000,-4147500.000)

to

Corner Coordinates:

Upper Left ( 281385.000,-4040680.000)

Lower Left ( 281385.000,-4254310.000)

Upper Right ( 525015.000,-4040680.000)

Lower Right ( 525015.000,-4254310.000)

Center ( 403200.000,-4147495.000)
Notice around 5 metres shift in Y value.

Do you guys have any idea what cause this shifting?

I initially want to attach the GeoTIFF file but as it is 55MB I don't think I could attach in this email as an attachment but it is just a free LANDSAT data in GeoTIFF I got from USGS using

    WRS-2 Path: 92 Row: 86 (Australia scene) from http://glovis.usgs.gov/

But I do attached the gdalinfo result for both GeoTIFF and its resulted netCDF (netCDF translated from GeoTIFF using gdal_translate).

Third, if I try to force using the specified corners when translating geotiff to netCDF file using
-projwin ulx uly lrx lry:
    Selects a subwindow from the source image for copying (like -srcwin) but with the corners given in georeferenced coordinates. 
-a_ullr ulx uly lrx lry:
    Assign/override the georeferenced bounds of the output file. This assigns georeferenced bounds to the output file, ignoring what would have been derived from the source file. 

such as: 
Upper Left  (-2641576.377,-1203225.344)
Lower Right ( 1856823.623,-5385325.344)

by running the below command:

gdal_translate -of netCDF -projwin -2641576.377 -1203225.344 1856823.623 -5385325.344 -a_ullr -2641576.377 -1203225.344 1856823.623 -5385325.344 Australia_Radiometric.tif out.nc

the resulted corners are always rounded in the netCDF file as shown in the netCDF gdalinfo below.

Driver: netCDF/Network Common Data Format
Files: out.nc
       out.nc.aux.xml
Size is 44984, 41821
Coordinate System is:
PROJCS["GDA94 / Geoscience Australia Lambert",
    GEOGCS["GDA94",
        DATUM["Geocentric_Datum_of_Australia_1994",
            SPHEROID["GRS 1980",6378137,298.2572221010002,
                AUTHORITY["EPSG","7019"]],
            AUTHORITY["EPSG","6283"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4283"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",-18],
    PARAMETER["standard_parallel_2",-36],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",134],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","3112"]]
Origin = (-2641580.000000000000000,-1203230.000000000000000)
Pixel Size = (100.000000000000000,-100.000000000000000)
Metadata:
  NC_GLOBAL#Conventions=CF-1.0
  Band1#_FillValue=-9.999900e+04
  Band1#grid_mapping=lambert_conformal_conic
  Band1#long_name=GDAL Band Number 1
  lambert_conformal_conic#Northernmost_Northing=-1.20323e+06
  lambert_conformal_conic#Southernmost_Northing=-5.38533e+06
  lambert_conformal_conic#Easternmost_Easting=1.85682e+06
  lambert_conformal_conic#Westernmost_Easting=-2.64158e+06
  lambert_conformal_conic#spatial_ref=PROJCS["GDA94 / Geoscience Australia Lambert",GEOGCS["GDA94",DATUM["Geocentric_Datum_of_Australia_1994",SPHEROID["GRS 1980",6378137,298.2572221010002,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6283"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4283"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",-18],PARAMETER["standard_parallel_2",-36],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",134],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","3112"]]
  lambert_conformal_conic#GeoTransform=-2.64158e+06 100 0 -1.20323e+06 0 -100 
  lambert_conformal_conic#grid_mapping_name=lambert_conformal_conic
  lambert_conformal_conic#standard_parallel_1=-1.800000e+01
  lambert_conformal_conic#standard_parallel_2=-3.600000e+01
  lambert_conformal_conic#latitude_of_projection_origin=0.000000e+00
  lambert_conformal_conic#longitude_of_central_meridian=1.340000e+02
  lambert_conformal_conic#false_easting=0.000000e+00
  lambert_conformal_conic#false_northing=0.000000e+00
  AREA_OR_POINT=Area
Corner Coordinates:
Upper Left  (-2641580.000,-1203230.000) (110d51' 4.41"E,  8d 7' 9.45"S)
Lower Left  (-2641580.000,-5385330.000) (101d31'55.67"E, 44d46'49.25"S)
Upper Right ( 1856820.000,-1203230.000) (150d21'54.61"E,  9d11'22.68"S)
Lower Right ( 1856820.000,-5385330.000) (157d 4'51.47"E, 46d15'48.60"S)
Center      ( -392380.000,-3294280.000) (129d55'18.53"E, 29d 4'28.92"S)
Band 1 Block=44984x1 Type=Float32, ColorInterp=Gray
  NoData Value=-99999
  Metadata:
    NETCDF_VARNAME=Band1

================================================================================
I was actually expecting these kind of results:

Origin = (-2641576.377182859461755,-1203225.344003787031397)
Pixel Size = (100.000000000000000,-100.000000000000000)
...
...
Corner Coordinates:
Upper Left  (-2641576.377,-1203225.344) (110d51' 4.55"E,  8d 7' 9.33"S)
Lower Left  (-2641576.377,-5385325.344) (101d31'55.88"E, 44d46'49.14"S)
Upper Right ( 1856823.623,-1203225.344) (150d21'54.71"E,  9d11'22.52"S)
Lower Right ( 1856823.623,-5385325.344) (157d 4'51.59"E, 46d15'48.44"S)
Center      ( -392376.377,-3294275.344) (129d55'18.67"E, 29d 4'28.77"S)

which is the result of running the below command:

gdal_translate -of GTiff -projwin -2641576.377 -1203225.344 1856823.623 -5385325.344 -a_ullr -2641576.377 -1203225.344 1856823.623 -5385325.344 Australia_Radiometric.tif out.tif

Any thoughts would be really appreciated.

Thank you.

Regards,

Hendy Sumanto
Software Developer
http://www.vpac.org


_______________________________________________
Discuss mailing list
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

-- 
Hendy Sumanto
Software Developer

Victorian Partnership for Advanced Computing (VPAC)
Innovation Powered by Advanced Computing
http://www.vpac.org
t: +61 3 9020 0191 (TC)
t: +61 3 9647 5437 (FB)
f: +61 3 9646 7787
m: +61 4 1258 0874



More information about the Discuss mailing list