Closed danhamill closed 2 years ago
A troubleshooting measure: Do you have any errors if you use gdal_translate to go from NetCDF to say, GeoTIFF?
No errors. gdalsrsinfo
appears to be the same for the .nc
and .tif
file formats
C:\workspace\temp\Data>gdal_translate -of GTIFF UTQI_SM_030m_roff_2003_04_10.nc UTQI_SM_030m_roff_2003_04_10.tif
Input file size is 391, 424
0...10...20...30...40...50...60...70...80...90...100 - done.
C:\workspace\temp\Data>gdalsrsinfo UTQI_SM_030m_roff_2003_04_10.nc
PROJ.4 : +proj=utm +zone=4 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
OGC WKT :
PROJCS["UTM Zone 4, Northern Hemisphere",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9108"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-159],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
UNIT["Meter",1]]
C:\workspace\temp\Data>gdalsrsinfo UTQI_SM_030m_roff_2003_04_10.tif
PROJ.4 : +proj=utm +zone=4 +datum=WGS84 +units=m +no_defs
OGC WKT :
PROJCS["WGS 84 / UTM zone 4N",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-159],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH],
AUTHORITY["EPSG","32604"]]
I added handling for the transverse mercator projection. There was none there previously and given that no one has reported this before, I suspect it's not that common for distributing scientific data.
The projection parameters look correct for the imported grid:
The grid data looks like:
Notice the pathname parts have no parameters. I'm guessing this is because the file is not CF, so vortex can't provide all of the automated parsing that it normally would.
Thanks Tom!
Thanks Tom.
The data are from the north slope of Alaska. It’s not surprising that most people don’t use that projection. I wonder how accurate utm grids are that far north.
I’ll report back on our tests.
On December 15, 2021, nnk2193 @.***> wrote:
I added an rc release here https://github.com/HydrologicEngineeringCenter/Vortex/releases/tag/v0.10.27- rc.1 if you want to test.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HydrologicEngineeringCenter/Vortex/issues/55#issuecomment- 995357560, or unsubscribe https://github.com/notifications/unsubscribe- auth/ACX5GUQZPIZKKTZTXNZK3L3URE6FHANCNFSM5KEIBVUA.
Tests are looking good!
With this grid UTQI_SM_030m_roff_2003_04_10.zip I am trying to import to dss and get the following traceback:
The source grid is in EPSG 32604. The nedcdf file originated from SnowModel and does not follow the CF metadata Conventions. Do you think this is realted to the projection, or does it have to do with the structure of the NetCDF file?