Sea Level Anomaly from the PO.DAAC

Use this Forum to find information on, or ask a question about, NASA Earth Science data.
Post Reply
bruce
Posts: 85
Joined: Thu Mar 17, 2005 4:36 pm America/New_York
Answers: 0

Sea Level Anomaly from the PO.DAAC

by bruce » Tue Jan 15, 2019 2:44 pm America/New_York

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

Tags:

OB.DAAC - SeanBailey
User Services
User Services
Posts: 1464
Joined: Wed Sep 18, 2019 6:15 pm America/New_York
Answers: 1
Been thanked: 5 times

Sea Level Anomaly from the PO.DAAC

by OB.DAAC - SeanBailey » Wed Jan 30, 2019 2:12 pm America/New_York

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:
$ nccopy -VSLA ssh_grids_v1609_2018061812_i.nc.nc sla-only.nc
Add Lat and Lon bands using the Band Maths function:

Latitude = Y * 0.166666667 - 80
Longitude = X * 0.166666667

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

bruce
Posts: 85
Joined: Thu Mar 17, 2005 4:36 pm America/New_York
Answers: 0

Sea Level Anomaly from the PO.DAAC

by bruce » Wed Jan 30, 2019 4:09 pm America/New_York

Tanks!  I'll give it a whirl and see if I can make things work :)

bruce
Posts: 85
Joined: Thu Mar 17, 2005 4:36 pm America/New_York
Answers: 0

Sea Level Anomaly from the PO.DAAC

by bruce » Tue Feb 05, 2019 10:40 am America/New_York

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.

gnwiii
Posts: 713
Joined: Fri Jan 29, 2021 5:51 pm America/New_York
Answers: 2
Has thanked: 1 time

Sea Level Anomaly from the PO.DAAC

by gnwiii » Wed Feb 06, 2019 11:07 am America/New_York

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.DAAC - SeanBailey
User Services
User Services
Posts: 1464
Joined: Wed Sep 18, 2019 6:15 pm America/New_York
Answers: 1
Been thanked: 5 times

Sea Level Anomaly from the PO.DAAC

by OB.DAAC - SeanBailey » Wed Feb 06, 2019 11:44 am America/New_York

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:
fixSLA.py <input file from PO.DAAC> <my new filename>
attachment 1

bruce
Posts: 85
Joined: Thu Mar 17, 2005 4:36 pm America/New_York
Answers: 0

Sea Level Anomaly from the PO.DAAC

by bruce » Thu Feb 07, 2019 7:44 am America/New_York

Da bomb!  Thanks Sean, you da man!

OB.DAAC - SeanBailey
User Services
User Services
Posts: 1464
Joined: Wed Sep 18, 2019 6:15 pm America/New_York
Answers: 1
Been thanked: 5 times

Sea Level Anomaly from the PO.DAAC

by OB.DAAC - SeanBailey » Thu Feb 07, 2019 8:11 am America/New_York

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

Post Reply