it's almost right, but stored in float32 with fuzz - degenerate rectilinear is a terrible way to store a regular grid ... is it regular? did they make a mistake? the coords and the metadata don't agree, it's impossible to be sure and that's normal in netcdf, a regular grid is six numbers (maybe eight) and a crs. sadly xarray has elevated this practice to world standard - I appreciate odc has helpers, but that's python - I R has helpers also of course, I like to keep as our in GDAL as much as possible so it's lang-agnostic
Created
March 1, 2024 21:08
-
-
Save mdsumner/e8dc2b66712fadab84b29893db6965af to your computer and use it in GitHub Desktop.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
it's not possible to determine what they intended, and the netcdf metadata attributes disagree with the actual coords in there - I'll hit them up with questions when I have the story laid out fully, it's easy to fix - it's an upfront a_ullr or a_gt metadata assignment for gdal, but there's a whole family of stuff to fix as well like change the offset scale to give celsius not F (so lazy load can act for longer), and actually specify the crs - I don't know how netcdf assigns fixes for metadata, but with gdal it's just -a_ args with VRT or the vrt:// protocol - also I wonder if you try to stream it does the netcdf side use #mode=bytes or does it use gdal vsicurl and re-generate the lon lat coords from gdal's slightly off transform? when I do it with osgeo.gdal I stream it, and there's no crufty coord arrays used at all