[gdal-dev] another problem HDF5

[Even Rouault]

Hi,

oh well, so this i actually a HDF5 file using netCDF conventions, but 
likely created with the HDF5 API itself. Per se, this isn't the issue, 
as you've figured it, we can convince the netCDF driver to open it. The 
lack of CRS comes from the fact that the land_mask_map variable has this 
attribute:

                 land_mask_map:grid_mapping = "crs: grid_x crs: grid_y" ;

Which tries to point to the "crs" variable where the CRS is defined. In 
99% of the products, the value of grid_mapping would be just "crs", and 
life would be good.

Here they use the "second format" for grid_mapping, described at 
https://cfconventions.org/Data/cf-conventions/cf-conventions-1.11/cf-conventions.html#grid-mappings-and-projections

"In the second format, it is a blank-separated list of words 
"<gridMappingVariable>: <coordinatesVariable> [<coordinatesVariable> …​] 
[<gridMappingVariable>: <coordinatesVariable>…​]", which identifies one 
or more grid mapping variables, and with each grid mapping associates 
one or more coordinatesVariables, i.e. coordinate variables or auxiliary 
coordinate variables."

That documentation isn't 100% crystal clear but the later example 5.10 
"British National Grid" gives an example:

temp:grid_mapping = "crsOSGB: x y crsWGS84: lat lon" ;

So you can point to several crs variables, but for each you need to 
define *all* the relevant axis. The way it is done in the product you 
point doesn't match that philosophy (if they wanted to use the second 
format that should rather set "crs: grid_x grid_y", but using the second 
format here is just asking for troubles), and GDAL doesn't manage to 
parse it.

You could tune netCDFDataset::SetProjectionFromVar() to recognize this 
weird value for grid_mapping in netCDFDataset::SetProjectionFromVar(), 
around line 3287, but I don't feel myself personally motivated to do 
that, if that product is just an outlier, so I leave it to you as an 
exercise if you wish :-). I guess just testing against the hardcoded 
"crs: grid_x crs: grid_y" value would be good enough to handle that outlier.

(Someone, super bored, should author a book about with horror stories 
with netCDF and HDF georeferencing. There's a lot of material. Although 
likely not to be a best seller)

Even

Le 30/04/2024 à 09:45, Michael Sumner via gdal-dev a écrit :
> This time, with:
>
> https://n5eil01u.ecs.nsidc.org/ATLAS/ATL20.004/2018.10.14/ATL20-01_20181001010615_00370101_004_01.h5
>
> NETCDF gets the geotransform (from x_grid,y_grid which report in the 
> metadata) but no crs:
>
>   gdalinfo NETCDF:ATL20-02_20181001010615_00370101_004_01.h5 -sd 1 -nomd
> Driver: netCDF/Network Common Data Format
> Files: ATL20-02_20181001010615_00370101_004_01.h5
> Size is 316, 332
> Origin = (-3950000.000000000000000,4350000.000000000000000)
> Pixel Size = (25000.000000000000000,-25000.000000000000000)
> Corner Coordinates:
> Upper Left  (-3950000.000, 4350000.000)
> Lower Left  (-3950000.000,-3950000.000)
> Upper Right ( 3950000.000, 4350000.000)
> Lower Right ( 3950000.000,-3950000.000)
> Center      (       0.000,  200000.000)
> Band 1 Block=500x500 Type=Float64, ColorInterp=Undefined
>   Unit Type: degrees_north
>
>
> HDF5 doesn't get geotransform or crs:
>
> gdalinfo ATL20-02_20181001010615_00370101_004_01.h5 -sd 1 -nomd
> Driver: HDF5Image/HDF5 Dataset
> Files: ATL20-02_20181001010615_00370101_004_01.h5
> Size is 316, 332
> Corner Coordinates:
> Upper Left  (    0.0,    0.0)
> Lower Left  (    0.0,  332.0)
> Upper Right (  316.0,    0.0)
> Lower Right (  316.0,  332.0)
> Center      (  158.0,  166.0)
> Band 1 Block=500x500 Type=Float32, ColorInterp=Undefined
>   NoData Value=3.4028235e+38
>
> This is unproblematically NSIDC 25km south, there's no mix of poles in 
> this one. I honestly don't know what to expect from these files 
> generally though I get my hopes up sometimes haha.
>
> I'll have to keep notes and explore more deeply with native HDF5 tools.
>
> Cheers, Mike
>
>
>
>
> -- 
> Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> Hobart, Australia
> e-mail: mdsumner at gmail.com
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240430/51b20ccf/attachment.htm>