Hi SNAP devs,
I’m here again with a new topic related to SLSTR L2 Reprojection.
My usual processing chain is Read->Subset->Reproject->Write
I got a sample from the public test data set ftp:
ftp://ftp_tds-s3mpc:smwF298B@ftp.acri-cwa.fr/TDS_SLSTR_20150717/S3A_SL_2_WST____20071229T095534_20071229T114422_20150702T151300_6528_064_365______MAR_D_NT_001.SEN3.zip
This sample has data crossing the dateline. (Locally, I have also some smaller samples crossing the dateline)
I have encountered a couple of issues dealing with them.
The first one is that without any special JVM argument being configured, I’m getting this exception:
exception1.log (2.6 KB)
Taking a look at the code, I see there are 2 PixelGeoCoding classes.
So I have tried with the alternate one by specifying:
-Dsnap.useAlternatePixelGeoCoding=true
resulting into exception2.log (2.4 KB)
Taking a look at the code again, I have added this argument to try to proceed with the processing:
-Dsnap.pixelGeoCoding.useTiling=false
Which at this point produced a result:
A world wide dataset (minX=-180° and maxX=180°) with 2 small regions of valid pixels on the left/right edges: let say in the longitude ranges [-180, -160] and [130,180] respectively). All the pixels in the middle area [-160,130] are NaN.
See screenshot:
First question is: what would be the best approach to deal with this scenario?
I see there is a geoRegion parameter in Subset Op so I was thinking about defining 2 subsets with 2 geometries (rectangles) splitting dataset in 2 halves, with longitude ranges [-180°, 0] and [0,180°]
Do you think it would make sense? Do you have any experience to share about this topic?
I have tried that approach by defining a GeoRegion WKT but I’m getting the same result as before.
Do you have any feedbacks on the above notes and exceptions?
The second issue I have is that using the default PixelGeoCoding2 (instead of GeoPixelCoding) takes very long.
Using a subset with 300 rows, a TileCache of 1.5GB and Heap of 2.4GB tooks 3’20’’ to produce a 36000x800 pixels image (due to the wide dataset covering -180, 180).
Taking a look with a profiler it seems it’s spending lot of time doing several PixelGeoCoding2.getPixelPos ->PixelFinder.findPixelPos resulting into getTile calls which get locked when accessing the tileCache (synchronized access).
I have tried with the ConcurrentTileCache (based on Guava) available in jai-ext project and that time went down to 1’50".
However, the alternate PixelGeoCoding generates the output faster: only 25".
The problem is that it creates artifacts on the subset edges/data edges.
It looks like cloned rows on the edge, resulting into some strange borders.
See this image (hope you can notice the pixel being copied on the edge, remarked by the red polygon I have added to the picture):
Is there any way to get rid of these artifacts?
As usual, thank you very much for your great assistance.
Cheers,
Daniele
