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: mdsum...@gmail.com
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
