SLSTR L2 Reprojection issue (PixelGeoCoding vs PixelGeoCoding2). Border artifacts and Tile access exceptions

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:
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:

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:

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.

did you have any chance to take a look on the issue?
I’m having similar problems with OLCI L1 data crossing the dateline. Activating -Dsrtbx.reader.olci.pixelGeoCoding=true I get better results. However it takes very long (due to accessing 1 by 1 the coordinates pixels). Moreover, I get strange NaN pattern near the corner (see the scattered white pixels in this QGIS preview):

I’m digging into the code trying to find the cause. Please, let me know if you have any suggestion or hints about it.


Sorry Daniele for not being very responsive these days. Currently I can’t say way we’ll have the time to look into it. Hopefully it will not take to long.
Have you found meanwhile any new insights?

Hi Marco,
not so much for the moment. I had to focus on other processing tasks.
The only thing I have found is some inconsistency in the PixelGeoCoding class which was causing the NPE.
The way the targetRasterFormatTag is created starts from an ImageLayout layout which always set a DataBuffer.TYPE_FLOAT.
Then the processFloatLoop/Double destAcc.getDoubleDataArrays will get a null array since it has been initialized as FLOAT instead.


The NPE in the processFloatLoop and processDoubleLoop should be fixed now.
maybe you give it a try.


Hi Marco,
thanks for the feedback and the fix.

I’ll give it a try in the next days.