Mosaic over dateline giving bad results

Hi,
I am trying use a gpt graph to mosaic several MODIS Aqua L2 pass files to cover the Chukchi Sea (-179 to -155 longitude and 63 to 75 latitude). The issue seems to be that some of the L2 files I receive from NASA have data over the dateline (positive longitudes). My gpt graph uses the coordinates above. The results of the mosaic are strange with heavy striping in some images that is not present in the input files. I have also tried a subset operator on each input file before mosaicing. This improves the results, but leads to incredibly long processing times (~15min/image).

Any ideas are appreciated.

Thanks,

Dan

Yes, it is known that there are issues if scenes cross the dateline (SNAP-1319). But actually only if it crosses the dateline, but you are only close.
Why subsetting slows down the processing is not clear to me. To which format do you save the subsetted data?

Thanks, Marco. I think the issue may be that some of the input scenes bleed over the dateline. The region I ask for in the output does not. As far as a format for the subsetted files, I tried different types of NetCDF (NetDCF4-BEAM, NetCDF4-CF). Do you have suggestions for this?

If you already tried NetCDF4-BEAM, then I have no further suggestion. I just thought that BEAM-DIMAP or NetCDF4-BEAM could improve the performance compared to NetCDF4-CF.

Just to minimize confusion, the underlying problem is that level-2 data are stored as rectangular arrays, so there isn’t a simple way to cut off scanlines that cross the dateline. NASA’s workflow uses binning and avoids the extemely tricky details that mosaic gets wrong. It might be worth trying to mark data on the “wrong” side of the dateline as invalid. For your region of interest, it is the ends of scanlines that cause problems. These problematic data have sub-optimal sun-satellite geometry so are less reliable than data near the centerline, which means you shouldn’t lose much information by excluding them from a mosaic.

It is also worth mentioning that developers are a scarce resource in this field so bugs must be triaged. Support for new sensors and standard workflows deserve priority. NASA has announced major improvements to their binning algorithms for the next OCSSW software release. I expect the new algorithms to increase the range of use cases for which binning is appropriate.

Thanks, George

I am going to try l2bin/l3mapgen as Sean suggests.