[gdal-dev] HDF data mis-applied sinusoidal

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] HDF data mis-applied sinusoidal

Michael Sumner-2
Hello, these data in HDF4 format are interpreted as being in sinusoidal projection, I guess some conflation with the MODIS logic about some products (?). 


Particular file is here, but note there's also an auxiliarly .hdf.xml with it:  ftp://ftp.glcf.umd.edu/glcf/GLASS/ABD/MODIS/0.05D/2013/GLASS02B06.V04.A2013169.2017128.hdf

A plot of the first subdataset shows that it is trivially in regular longlat (or eqc), the gdalinfo output is below.  

I'd appreciate any insights into why this is interpreted this way, and whether the GDAL detection logic could be improved - or whether the data providers need to update the internal metadata. 

Cheers, Mike. 

gdalinfo --version GDAL 2.3.2, released 2018/09/21

gdalinfo HDF4_EOS:EOS_GRID:"GLASS02B06.V04.A2013169.2017128.hdf":GLASS02B06:ABD_BSA_VIS
Driver: HDF4Image/HDF4 Dataset
Files: GLASS02B06.V04.A2013169.2017128.hdf
Size is 7200, 3600
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["Unknown datum based upon the custom spheroid",
        DATUM["Not specified (based on custom spheroid)",
            SPHEROID["Custom spheroid",6371007.181,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Sinusoidal"],
    PARAMETER["longitude_of_center",0],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]
Origin = (-20015109.353999998420477,10007554.676999999210238)
Pixel Size = (154.437572175972150,-308.875144351944300)
Metadata:
  add_offset=0
  add_offset_err=0
  ASSOCIATEDINSTRUMENTSHORTNAME.1=AVHRR
  ASSOCIATEDPLATFORMSHORTNAME.1=NOAA
  ASSOCIATEDSENSORSHORTNAME.1=AVHRR
  BANDDEFINITION=Surface
  CHARACTERISTICBINSIZE=926.6
  DATACOLUMNS=7200
  DATAROWS=3600
  DATASETNAME=GLASS02B06
  DAYNIGHTFLAG=Both
  EASTHBOUNDINGCOORDINATE=180
  EXCLUSIONGRINGFLAG=N
  GLOBALGRIDCOLUMNS=7200
  GLOBALGRIDROWS=3600
  GRIDTYPE=Geographic Lat/Lon
  GRINGPOINTLATITUDE.1=90,90,-90,-90
  GRINGPOINTLONGITUDE.1=-180,180,180,-180
  GRINGPOINTSEQUENCENO.1=1,2,3,4
  HDFEOSVersion=HDFEOS_V2.16
  HORIZONTALTILENUMBER=00
  HORIZONTALTILENUMBER=00
  INPUTFILESNAME=Multi-Source Data
  INPUTPOINTER=Multi-Source Data
  INSTITUTENAME=BEIJING
  LOCALGRANULEID=GLASS02B06.V04.A2013169.2017128.hdf
  LOCALVERSIONID=V04
  long_name=Black-sky Albedo in Visible band
  NORTHBOUNDINGCOORDINATE=90
  PARAMETERNAME.1=GLASS02B06
  PGEVERSION=V04
  PROCESSINGENVIRONMENT=High Performance Computing System
  PRODUCTDATEANDTIME=2017-05-08 16:00:12
  PRODUCTIONDATETIME=2017-05-08 16:00:12
  PRODUCTNAME=Surface
  PRODUCTQUALITY=CLOUDREMOVED
  REPROCESSINGACTUAL=reprocessed
  REPROCESSINGPLANNED=further update is anticipated
  scale_factor=0.0001
  scale_factor_err=0
  SHORTNAME=GLASS02B06
  SOUTHBOUNDINGCOORDINATE=-90
  TILENUMBER=H00V00
  units=Albedo,no units
  valid_range=0, 10000
  VERSIONID=1
  VERTICALTILENUMBER=00
  VERTICALTILENUMBER=00
  WESTHBOUNDINGCOORDINATE=-180
  _FillValue=-1
Corner Coordinates:
Upper Left  (-20015109.354,10007554.677) (124d17'29.21"W, 90d 0' 0.00"N)
Lower Left  (-20015109.354, 8895604.157) ( 43d25'16.73"E, 80d 0' 0.00"N)
Upper Right (-18903158.834,10007554.677) ( 77d21'53.56"W, 90d 0' 0.00"N)
Lower Right (-18903158.834, 8895604.157) (101d 0'32.47"E, 80d 0' 0.00"N)
Center      (-19459134.094, 9451579.417) (152d 6' 0.67"E, 85d 0' 0.00"N)
Band 1 Block=7200x3600 Type=Int16, ColorInterp=Gray
  Description = Black-sky Albedo in Visible band
  NoData Value=-1
  Unit Type: Albedo,no units
  Offset: 0,   Scale:
--
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: HDF data mis-applied sinusoidal

Andre Joost
Hi Michael,

running eosdump on the file, I get:

File Size: 94926773
Number of grids: 1
Number of swaths: 0
Number of points: 0
Grid: GLASS02B06
        projection: SNSOID
        griddataclash:


   GRID GLASS02B06 {{{
     xdim: 7200
     ydim: 3600
     upleft: -2.00151e+07, 1.00076e+07
     lowright: -1.89032e+07, 8.8956e+06
     PROJECTION {
       projection: 16
       zone: -1
       sphere: -1
       param: ...
         6.37101e+06 0 0 0 0 0 0 0
         0 0 0 0 0 3.14511e+35 4.21472e-153 1.72352e+45
       pix: 0
       origin: 0
   }

So they defined the wrong projection, and gdal can't do much about it.

You can sanitize it with gdal_translate -a_ullr -180 90 180 -90 -a_srs
EPSG:4326 src dst

HTH,
Andre Joost

Am 29.11.18 um 21:31 schrieb Michael Sumner:

> Hello, these data in HDF4 format are interpreted as being in sinusoidal
> projection, I guess some conflation with the MODIS logic about some
> products (?).
>
> ftp://ftp.glcf.umd.edu/glcf/GLASS/ABD/MODIS/0.05D/2013/
>
> Particular file is here, but note there's also an auxiliarly .hdf.xml with
> it:
> ftp://ftp.glcf.umd.edu/glcf/GLASS/ABD/MODIS/0.05D/2013/GLASS02B06.V04.A2013169.2017128.hdf
>
> A plot of the first subdataset shows that it is trivially in regular
> longlat (or eqc), the gdalinfo output is below.
>
> I'd appreciate any insights into why this is interpreted this way, and
> whether the GDAL detection logic could be improved - or whether the data
> providers need to update the internal metadata.
>
> Cheers, Mike.
>
> gdalinfo --version GDAL 2.3.2, released 2018/09/21
>
> gdalinfo
> HDF4_EOS:EOS_GRID:"GLASS02B06.V04.A2013169.2017128.hdf":GLASS02B06:ABD_BSA_VIS
> Driver: HDF4Image/HDF4 Dataset
> Files: GLASS02B06.V04.A2013169.2017128.hdf
> Size is 7200, 3600
> Coordinate System is:
> PROJCS["unnamed",
>      GEOGCS["Unknown datum based upon the custom spheroid",
>          DATUM["Not specified (based on custom spheroid)",
>              SPHEROID["Custom spheroid",6371007.181,0]],
>          PRIMEM["Greenwich",0],
>          UNIT["degree",0.0174532925199433]],
>      PROJECTION["Sinusoidal"],
>      PARAMETER["longitude_of_center",0],
>      PARAMETER["false_easting",0],
>      PARAMETER["false_northing",0],
>      UNIT["Meter",1]]
> Origin = (-20015109.353999998420477,10007554.676999999210238)
> Pixel Size = (154.437572175972150,-308.875144351944300)
> Metadata:
>    add_offset=0
>    add_offset_err=0
>    ASSOCIATEDINSTRUMENTSHORTNAME.1=AVHRR
>    ASSOCIATEDPLATFORMSHORTNAME.1=NOAA
>    ASSOCIATEDSENSORSHORTNAME.1=AVHRR
>    BANDDEFINITION=Surface
>    CHARACTERISTICBINSIZE=926.6
>    DATACOLUMNS=7200
>    DATAROWS=3600
>    DATASETNAME=GLASS02B06
>    DAYNIGHTFLAG=Both
>    EASTHBOUNDINGCOORDINATE=180
>    EXCLUSIONGRINGFLAG=N
>    GLOBALGRIDCOLUMNS=7200
>    GLOBALGRIDROWS=3600
>    GRIDTYPE=Geographic Lat/Lon
>    GRINGPOINTLATITUDE.1=90,90,-90,-90
>    GRINGPOINTLONGITUDE.1=-180,180,180,-180
>    GRINGPOINTSEQUENCENO.1=1,2,3,4
>    HDFEOSVersion=HDFEOS_V2.16
>    HORIZONTALTILENUMBER=00
>    HORIZONTALTILENUMBER=00
>    INPUTFILESNAME=Multi-Source Data
>    INPUTPOINTER=Multi-Source Data
>    INSTITUTENAME=BEIJING
>    LOCALGRANULEID=GLASS02B06.V04.A2013169.2017128.hdf
>    LOCALVERSIONID=V04
>    long_name=Black-sky Albedo in Visible band
>    NORTHBOUNDINGCOORDINATE=90
>    PARAMETERNAME.1=GLASS02B06
>    PGEVERSION=V04
>    PROCESSINGENVIRONMENT=High Performance Computing System
>    PRODUCTDATEANDTIME=2017-05-08 16:00:12
>    PRODUCTIONDATETIME=2017-05-08 16:00:12
>    PRODUCTNAME=Surface
>    PRODUCTQUALITY=CLOUDREMOVED
>    REPROCESSINGACTUAL=reprocessed
>    REPROCESSINGPLANNED=further update is anticipated
>    scale_factor=0.0001
>    scale_factor_err=0
>    SHORTNAME=GLASS02B06
>    SOUTHBOUNDINGCOORDINATE=-90
>    TILENUMBER=H00V00
>    units=Albedo,no units
>    valid_range=0, 10000
>    VERSIONID=1
>    VERTICALTILENUMBER=00
>    VERTICALTILENUMBER=00
>    WEBSITE=http://glass-product.bnu.edu.cn
>    WESTHBOUNDINGCOORDINATE=-180
>    _FillValue=-1
> Corner Coordinates:
> Upper Left  (-20015109.354,10007554.677) (124d17'29.21"W, 90d 0' 0.00"N)
> Lower Left  (-20015109.354, 8895604.157) ( 43d25'16.73"E, 80d 0' 0.00"N)
> Upper Right (-18903158.834,10007554.677) ( 77d21'53.56"W, 90d 0' 0.00"N)
> Lower Right (-18903158.834, 8895604.157) (101d 0'32.47"E, 80d 0' 0.00"N)
> Center      (-19459134.094, 9451579.417) (152d 6' 0.67"E, 85d 0' 0.00"N)
> Band 1 Block=7200x3600 Type=Int16, ColorInterp=Gray
>    Description = Black-sky Albedo in Visible band
>    NoData Value=-1
>    Unit Type: Albedo,no units
>    Offset: 0,   Scale:
>
>
>
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: HDF data mis-applied sinusoidal

Michael Sumner-2
Thanks for clarifying!

Cheers, Mike

On Sat, Dec 1, 2018, 02:04 Andre Joost <[hidden email]> wrote:
Hi Michael,

running eosdump on the file, I get:

File Size: 94926773
Number of grids: 1
Number of swaths: 0
Number of points: 0
Grid: GLASS02B06
        projection: SNSOID
        griddataclash:


   GRID GLASS02B06 {{{
     xdim: 7200
     ydim: 3600
     upleft: -2.00151e+07, 1.00076e+07
     lowright: -1.89032e+07, 8.8956e+06
     PROJECTION {
       projection: 16
       zone: -1
       sphere: -1
       param: ...
         6.37101e+06 0 0 0 0 0 0 0
         0 0 0 0 0 3.14511e+35 4.21472e-153 1.72352e+45
       pix: 0
       origin: 0
   }

So they defined the wrong projection, and gdal can't do much about it.

You can sanitize it with gdal_translate -a_ullr -180 90 180 -90 -a_srs
EPSG:4326 src dst

HTH,
Andre Joost

Am 29.11.18 um 21:31 schrieb Michael Sumner:
> Hello, these data in HDF4 format are interpreted as being in sinusoidal
> projection, I guess some conflation with the MODIS logic about some
> products (?).
>
> ftp://ftp.glcf.umd.edu/glcf/GLASS/ABD/MODIS/0.05D/2013/
>
> Particular file is here, but note there's also an auxiliarly .hdf.xml with
> it:
> ftp://ftp.glcf.umd.edu/glcf/GLASS/ABD/MODIS/0.05D/2013/GLASS02B06.V04.A2013169.2017128.hdf
>
> A plot of the first subdataset shows that it is trivially in regular
> longlat (or eqc), the gdalinfo output is below.
>
> I'd appreciate any insights into why this is interpreted this way, and
> whether the GDAL detection logic could be improved - or whether the data
> providers need to update the internal metadata.
>
> Cheers, Mike.
>
> gdalinfo --version GDAL 2.3.2, released 2018/09/21
>
> gdalinfo
> HDF4_EOS:EOS_GRID:"GLASS02B06.V04.A2013169.2017128.hdf":GLASS02B06:ABD_BSA_VIS
> Driver: HDF4Image/HDF4 Dataset
> Files: GLASS02B06.V04.A2013169.2017128.hdf
> Size is 7200, 3600
> Coordinate System is:
> PROJCS["unnamed",
>      GEOGCS["Unknown datum based upon the custom spheroid",
>          DATUM["Not specified (based on custom spheroid)",
>              SPHEROID["Custom spheroid",6371007.181,0]],
>          PRIMEM["Greenwich",0],
>          UNIT["degree",0.0174532925199433]],
>      PROJECTION["Sinusoidal"],
>      PARAMETER["longitude_of_center",0],
>      PARAMETER["false_easting",0],
>      PARAMETER["false_northing",0],
>      UNIT["Meter",1]]
> Origin = (-20015109.353999998420477,10007554.676999999210238)
> Pixel Size = (154.437572175972150,-308.875144351944300)
> Metadata:
>    add_offset=0
>    add_offset_err=0
>    ASSOCIATEDINSTRUMENTSHORTNAME.1=AVHRR
>    ASSOCIATEDPLATFORMSHORTNAME.1=NOAA
>    ASSOCIATEDSENSORSHORTNAME.1=AVHRR
>    BANDDEFINITION=Surface
>    CHARACTERISTICBINSIZE=926.6
>    DATACOLUMNS=7200
>    DATAROWS=3600
>    DATASETNAME=GLASS02B06
>    DAYNIGHTFLAG=Both
>    EASTHBOUNDINGCOORDINATE=180
>    EXCLUSIONGRINGFLAG=N
>    GLOBALGRIDCOLUMNS=7200
>    GLOBALGRIDROWS=3600
>    GRIDTYPE=Geographic Lat/Lon
>    GRINGPOINTLATITUDE.1=90,90,-90,-90
>    GRINGPOINTLONGITUDE.1=-180,180,180,-180
>    GRINGPOINTSEQUENCENO.1=1,2,3,4
>    HDFEOSVersion=HDFEOS_V2.16
>    HORIZONTALTILENUMBER=00
>    HORIZONTALTILENUMBER=00
>    INPUTFILESNAME=Multi-Source Data
>    INPUTPOINTER=Multi-Source Data
>    INSTITUTENAME=BEIJING
>    LOCALGRANULEID=GLASS02B06.V04.A2013169.2017128.hdf
>    LOCALVERSIONID=V04
>    long_name=Black-sky Albedo in Visible band
>    NORTHBOUNDINGCOORDINATE=90
>    PARAMETERNAME.1=GLASS02B06
>    PGEVERSION=V04
>    PROCESSINGENVIRONMENT=High Performance Computing System
>    PRODUCTDATEANDTIME=2017-05-08 16:00:12
>    PRODUCTIONDATETIME=2017-05-08 16:00:12
>    PRODUCTNAME=Surface
>    PRODUCTQUALITY=CLOUDREMOVED
>    REPROCESSINGACTUAL=reprocessed
>    REPROCESSINGPLANNED=further update is anticipated
>    scale_factor=0.0001
>    scale_factor_err=0
>    SHORTNAME=GLASS02B06
>    SOUTHBOUNDINGCOORDINATE=-90
>    TILENUMBER=H00V00
>    units=Albedo,no units
>    valid_range=0, 10000
>    VERSIONID=1
>    VERTICALTILENUMBER=00
>    VERTICALTILENUMBER=00
>    WEBSITE=http://glass-product.bnu.edu.cn
>    WESTHBOUNDINGCOORDINATE=-180
>    _FillValue=-1
> Corner Coordinates:
> Upper Left  (-20015109.354,10007554.677) (124d17'29.21"W, 90d 0' 0.00"N)
> Lower Left  (-20015109.354, 8895604.157) ( 43d25'16.73"E, 80d 0' 0.00"N)
> Upper Right (-18903158.834,10007554.677) ( 77d21'53.56"W, 90d 0' 0.00"N)
> Lower Right (-18903158.834, 8895604.157) (101d 0'32.47"E, 80d 0' 0.00"N)
> Center      (-19459134.094, 9451579.417) (152d 6' 0.67"E, 85d 0' 0.00"N)
> Band 1 Block=7200x3600 Type=Int16, ColorInterp=Gray
>    Description = Black-sky Albedo in Visible band
>    NoData Value=-1
>    Unit Type: Albedo,no units
>    Offset: 0,   Scale:
>
>
>
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev