Anyone out there using SLA data from the PO.DAAC in SeaDAS? When I open this file (https://podaac-opendap.jpl.nasa.gov/opendap/allData/merged_alt/L4/cdr_grid_interim/ssh_grids_v1609_2018061812_i.nc.html) in SeaDAS, it's "upside down" and when you zoom in the "tiling" gets very funky...
Any advice greatly appreciated.
Bruce
Sea Level Anomaly from the PO.DAAC
-
OB.DAACx - SeanBailey
- Posts: 1519
- Joined: Wed Sep 18, 2019 6:15 pm America/New_York
- Been thanked: 9 times
Sea Level Anomaly from the PO.DAAC
Bruce,
Yes, that is rather odd. I am not sure exactly why it acts the way it does. SeaDAS is using the NetCDF-CF reader as it probably should (since the global metadata of the file say it's using the CF-1.6 convention). The behavior is the same in SNAP.
I don't have a quick solution and don't have the time to debug the reader. But a workaround would be the following:
Extract just the SLA product:
Add Lat and Lon bands using the Band Maths function:
Attach these bands for the pixel geocoding using Tools->Geo-coding Attach
It'll still be upside down, so then flip it using the Raster->Flip Data (vertically) function
You can then export the file as a new netCDF file.
You may find the min/max data ranges are wonky -but a quick manual rescale to reasonable values make the picture pretty again:
Sean
Yes, that is rather odd. I am not sure exactly why it acts the way it does. SeaDAS is using the NetCDF-CF reader as it probably should (since the global metadata of the file say it's using the CF-1.6 convention). The behavior is the same in SNAP.
I don't have a quick solution and don't have the time to debug the reader. But a workaround would be the following:
Extract just the SLA product:
$ nccopy -VSLA ssh_grids_v1609_2018061812_i.nc.nc sla-only.ncAdd Lat and Lon bands using the Band Maths function:
Latitude = Y * 0.166666667 - 80
Longitude = X * 0.166666667Attach these bands for the pixel geocoding using Tools->Geo-coding Attach
It'll still be upside down, so then flip it using the Raster->Flip Data (vertically) function
You can then export the file as a new netCDF file.
You may find the min/max data ranges are wonky -but a quick manual rescale to reasonable values make the picture pretty again:
Sean
Sea Level Anomaly from the PO.DAAC
Works as advertised. Thanks! But of course a couple of follow-on questions...
Is there a mechanism to set the min/max in the netCDF so I don't have to set it each time I load the file?
Is it possible to script the geo-coding and flipping steps (I may have 100's of these to do at some point)?
TIA.
Is there a mechanism to set the min/max in the netCDF so I don't have to set it each time I load the file?
Is it possible to script the geo-coding and flipping steps (I may have 100's of these to do at some point)?
TIA.
Sea Level Anomaly from the PO.DAAC
For batch processing you could try GDAL. VRT files can sometimes make wonky raster data usable by saving to a "clean" geotiff or netcdf file.
-
OB.DAACx - SeanBailey
- Posts: 1519
- Joined: Wed Sep 18, 2019 6:15 pm America/New_York
- Been thanked: 9 times
Sea Level Anomaly from the PO.DAAC
Bruce,
I felt challenged, so whipped up a python script to "fix" the SLA files (a for loop in your favorite shell can be used to batch process, or edit the attached script to do that)
As for the color, yes, there's a way - see the help for the color manager tool. It has instructions for adding user-defined "color schemes".
Sean
Note: here's how to run the "fixSLA.py" script:
I felt challenged, so whipped up a python script to "fix" the SLA files (a for loop in your favorite shell can be used to batch process, or edit the attached script to do that)
As for the color, yes, there's a way - see the help for the color manager tool. It has instructions for adding user-defined "color schemes".
Sean
Note: here's how to run the "fixSLA.py" script:
fixSLA.py <input file from PO.DAAC> <my new filename>attachment 1-
OB.DAACx - SeanBailey
- Posts: 1519
- Joined: Wed Sep 18, 2019 6:15 pm America/New_York
- Been thanked: 9 times
Sea Level Anomaly from the PO.DAAC
Just so no one gets the wrong idea, there isn't anything "wrong" with the SLA data from the PO.DAAC :grin: The fix was to make SeaDAS happy with it without modifying the Java code to add a product specific reader. While I've not confirmed the source of the netCDF reader's issues with these files, I believe it is because the SLA array is 3 dimensional, with time being one of the dimensions....since there's only a single time element, it's effectively a 2D array masquerading as a 3D one. What the script I wrote does is effectively flatten out that third dimension (and flip things to be "right" side up).
Sean
Sean