Mosaic/Reproject problems

[cortivo]

When I try to reproject or make a mosaic with some L2 imagens of SeaWiFS (and some times with Modis/Aqua) I get the error shown in the attached figure. I also read some post in this forum but I could not solve the problem.

Do anyone have had this problem or whats the solution?

[OB SeaDAS - knowles]

The particular example you show involves a SeaWiFS MLAC file.  The MLAC (merged LAC files) are a special case in that they can contain several pieces of a SeaWiFS orbit stitched together into a single file.  This means that adjacent pixels in the file raster across the stitch seam could have a large difference in latitude, which is likely what is causing the error.  See attached image of your example level2 file with latitude gridlines plots.

Alternatively, you can reproject this file using the OCSSW processors (l2bin followed by l3mapgen).  This works (see attached resultant image).

You mentioned that you have seen this occur in Aqua.  Can you let us know an Aqua filename where this occurs so we can look into this?

A cautionary note: the reproject tool cannot (at present) handle level2 files which contain a dateline (longitude=180) crossings.

thanks
Danny

[cortivo]

Hi.
Lets go Step by step.
In the previous post I mentioned problems about reprojection function of GPT with MLAC files, but we get that problem with Aqua images when we try do make a mosaic.

1) I am using the mosaic function of the GPT, because I need to crop some specifics regions on the South America. So I can merge the images (8D composition with 1km) and crop them at the same time. Thats the idea.  One of those regions is [20S, 30S]x[39W 49W]. The coast of Sao Paulo state.

2) The Aqua file that has problem is: A2003078171000.L2_LAC_OC.nc (I don't know if there are others...)
2.1) If we try to reproject the file, its works fine.
2.2) If we try to create a mosaic with only this file (or include others files) when the  Mosaic Bounds are greater than the bounds of the file, again it works fine. See figure-1.png
2.3) If we try to create it, but if we set the Mosaic Bounds as above ([20S, 30S]x[39W 49W]), we get the error. See attached figure-2.png.
2.4) If we add more images and set the above Mosaic Bounds the error remains. See figure-3.png

3) The image A2003078171000.L2_LAC_OC.nc is full of nan’s. So, in practice this image can be excluded of the mosaic. But, I'm not able to open all files in order to check if the image is full of nan's or no. Are there an automatic way to discover it (with ncdump, seadas etc...)?

4) If I reproject A2003078171000.L2_LAC_OC.nc and than try to make a mosaic I get the an error and the mosaic does not work. See attached figure-4 and figure-5.

5) I'm trying to make a mosaic because I can reproject and crop the images at the same time...

Thank you in advance for suggestions.
Fabio.

[OB SeaDAS - knowles]

This works for me, ... even the file with all NaNs (it's over land) and doing a Mosaic defining a region outside of the bounds of the file (your case 2).  I tested this on a Mac.  Can you tell us is your operating system?

Danny

[cortivo]

I tested in two systems. In both systems I get the same erros. See attached figures.
The sys1 is a normal desktop computer and the sys2 is a server.

[gnwiii]

You should look at the "os" entries on the "System Info" page from the "About SeaDAS" panel.  You may see something like:
os.arch  x86_64
os.name  Mac OS X
os.version  10.11.6 on macOS, or

os.arch  amd64
os.name  Linux
os.version  4.4.0-75-generic for linux.

Also, check that the module updates have been installed (use Tools/Module Manager/Module Updates).

[gnwiii]

Danny -- on a macOS El Capitan system I see the same "internal error ... Points of LinearRing do not form a closed linestring" -- as I recall, this is the normal result when the image does not overlap the Mosaic Bounds.

I tried the same operation in SNAP 6.0-preview 5 and did not get the error.

[cortivo]

Attached. Information about my personal desktop.
Also I checked the updates. All packages intalled are up to date

[OB SeaDAS - knowles]

The Aqua file in your example (A2003078171000.L2_LAC_OC.nc) has very unusual navigation.  The spacecraft was likely doing a yaw maneuver during acquisition.
See attached image for the abnormal geometry bounds of this file.

As a result, the latitudes and longitudes of adjacent pixels do not reliably increase/decrease as you go across the image.   If I change your region to use North=-24 or North=-19.0 instead of North=-20 then it works on my Linux for your example.  It just depends on which pixels are being crossed by the LinearRing.

The following command shows that 86% of the pixels of this file have navigation issues:
     %   ncdump -h A2003078171000.L2_LAC_OC.nc | grep ":NAVWARN"
        :NAVWARN = 86.20689f ;

The majority of files should have 0% NAVWARN pixels.

Regarding the total chlor_a NaNs, the closest thing might be to try:
     % ncdump -h A2003078171000.L2_LAC_OC.nc | grep ":PRODFAIL"
      :PRODFAIL = 100.f ;

However keep in mind that if any single product within the level2 file fails for a given pixel then this flag is triggered for that particular pixel. 

Also certainly LAND pixel percentage could help:
ncdump -h A2003078171000.L2_LAC_OC.nc | grep ":LAND"
        :LAND = 99.83806f ;

Danny

[OB SeaDAS - knowles]

Also regarding data issues for Aqua, Terra, and VIIRS you could try:
https://modaps.modaps.eosdis.nasa.gov/services/production/outages.html

The Land team has more detailed info on maneuvers and geolocation errors.  This page shows that there was a Drag delta-V on 2003078:
https://landweb.modaps.eosdis.nasa.gov/cgi-bin/QA_WWW/newPage.cgi?fileName=aqua2003&subdir=Maneuvers

Danny