Gpt Mosaic missing value

snap
#1

I am actually using gpt with the newest SeaDAS.

I am Mosaic’ing oisst files (for example one of these…( ftp://eclipse.ncdc.noaa.gov/pub/OI-daily-v2/NetCDF/2016/AVHRR/ ).
When I do it from the command line with gpt.sh the missing values are set to 0., which can actually be a valid value. Using the GUI (SeaDAS) it is handled correctly (missing (or land) = NaN).

Are there any tricks with maybe a conditional expression to achieve the same thing with gpt.sh?

Thanks,

#2

Replying to myself :slight_smile:
I came up with a solution, a bit clunky but it works for me. I added an offset to the variable sst first (say 10.), so that none of the valid values are 0, but I kept the missing value at the FillValue -999. Then Mosaic sst. Zeroes in the resulting sst can now only be missing values, not valid sst. I reset those pixels to -999, and then subtracted the offset (10.) from sst.

If there are more elegant solutions out there, I would like to hear.

#3

Actually it should be possible to define a condition in the graph XML file which does the same as in the GUI.
You can store the configuration (File -> Save Parameters) from the Mosaic GUI and use it as template for creating a graph file.
have you also asked the SeaDAS guys in their forum. Sometimes they have not only extend BEAM but also changed the source code and it works differently as an BEAM.
The current version of SeaDAS still uses BEAM as basis and not SNAP. But they plan to move.

#4

Thanks for your reply. Using the GUI parameters as a template gives the same result.

Now I realize that if I export the file with Mosaic in BEAM-DIMAP format it handles missing values fine (NaN stays NaN), but if I save it to netCDF4-CF it doesn’t (NaN becomes 0). This is why the GUI was working, because it outputs by default to BEAM-DIMAP.

Unfortunately I cannot work with BEAM-DIMAP in my application (IDL). I tried converting the BEAM-DIMAP files to netCDF4-CF with gpt.sh Write, but it reports all NaNs as 0. again :frowning:

#5

Probably the NaN values are defined by the valid pixel expression of the bands. This can not be stored in NetCDF.
You can remove those expressions from the band properties and recreate them in IDL.

#6

Ah, exactly! I see this in the Beam DIM file for the SST band:

        <NO_DATA_VALUE_USED>false</NO_DATA_VALUE_USED>
        <NO_DATA_VALUE>0.0</NO_DATA_VALUE>
        <VALID_MASK_TERM>sst_count &gt; 0</VALID_MASK_TERM>

So the way I understand is that it doesn’t use the ‘no_data_value’ of 0.0, but does use a VALID_MASK_TERM. So yes, I can use the other band in the netCDF file (sst_count) to mask the missing values. I checked, and indeed, they don’t mask out the valid 0.0 degree temperatures!

Thanks!