Thanks Even! I've reported it to the providers. (btw don't gazump me on that book)
Cheers, Mike On Tue, Apr 30, 2024 at 11:04 PM Even Rouault <even.roua...@spatialys.com> wrote: > 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 > listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- http://www.spatialys.com > My software is free, but my time generally not. > > -- 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
