<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>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:</p>
<p> land_mask_map:grid_mapping = "crs: grid_x crs:
grid_y" ;<br>
</p>
<p>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.</p>
<p>Here they use the "second format" for grid_mapping, described at
<a class="moz-txt-link-freetext" href="https://cfconventions.org/Data/cf-conventions/cf-conventions-1.11/cf-conventions.html#grid-mappings-and-projections">https://cfconventions.org/Data/cf-conventions/cf-conventions-1.11/cf-conventions.html#grid-mappings-and-projections</a></p>
<p>"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."</p>
<p>That documentation isn't 100% crystal clear but the later example
5.10 "British National Grid" gives an example:<br>
</p>
<pre>temp:grid_mapping = "crsOSGB: x y crsWGS84: lat lon" ;
</pre>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>(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)<br>
</p>
<p>Even<br>
</p>
Le 30/04/2024 à 09:45, Michael Sumner via gdal-dev a écrit :<br>
<blockquote type="cite"
cite="mid:CAAcGz99bXB460BF6Pn22+tyCi7OaUgxkFYc25+=wfGQKh-NWiQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">This time, with:
<div><br>
</div>
<div><a
href="https://n5eil01u.ecs.nsidc.org/ATLAS/ATL20.004/2018.10.14/ATL20-01_20181001010615_00370101_004_01.h5"
moz-do-not-send="true" class="moz-txt-link-freetext">https://n5eil01u.ecs.nsidc.org/ATLAS/ATL20.004/2018.10.14/ATL20-01_20181001010615_00370101_004_01.h5</a></div>
<div><br>
</div>
<div>NETCDF gets the geotransform (from x_grid,y_grid which
report in the metadata) but no crs: </div>
<div><br>
</div>
<div> gdalinfo
NETCDF:ATL20-02_20181001010615_00370101_004_01.h5 -sd 1 -nomd<br>
Driver: netCDF/Network Common Data Format<br>
Files: ATL20-02_20181001010615_00370101_004_01.h5<br>
Size is 316, 332<br>
Origin = (-3950000.000000000000000,4350000.000000000000000)<br>
Pixel Size = (25000.000000000000000,-25000.000000000000000)<br>
Corner Coordinates:<br>
Upper Left (-3950000.000, 4350000.000)<br>
Lower Left (-3950000.000,-3950000.000)<br>
Upper Right ( 3950000.000, 4350000.000)<br>
Lower Right ( 3950000.000,-3950000.000)<br>
Center ( 0.000, 200000.000)<br>
Band 1 Block=500x500 Type=Float64, ColorInterp=Undefined<br>
Unit Type: degrees_north<br>
<div><br>
</div>
</div>
<div><br>
</div>
<div>HDF5 doesn't get geotransform or crs: </div>
<div><br>
</div>
<div>gdalinfo ATL20-02_20181001010615_00370101_004_01.h5 -sd 1
-nomd<br>
Driver: HDF5Image/HDF5 Dataset<br>
Files: ATL20-02_20181001010615_00370101_004_01.h5<br>
Size is 316, 332<br>
Corner Coordinates:<br>
Upper Left ( 0.0, 0.0)<br>
Lower Left ( 0.0, 332.0)<br>
Upper Right ( 316.0, 0.0)<br>
Lower Right ( 316.0, 332.0)<br>
Center ( 158.0, 166.0)<br>
Band 1 Block=500x500 Type=Float32, ColorInterp=Undefined<br>
NoData Value=3.4028235e+38</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>I'll have to keep notes and explore more deeply with native
HDF5 tools. </div>
<div><br>
</div>
<div>Cheers, Mike</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">Michael Sumner<br>
Software and Database Engineer<br>
Australian Antarctic Division<br>
Hobart, Australia<br>
e-mail: <a href="mailto:mdsumner@gmail.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">mdsumner@gmail.com</a></div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>