Collocate OLCI+SLSTR problem

Optical Toolbox
#1

Hi there,

I am trying to overlay Optical data with Thermal data, with the “Collocate” function.
I have a problem when Saving the result:

2018-06-04_14-45-17
2018-06-04_14-45-171093×632 531 KB

CPU goes up to 100% very quick…I had to stop the processing, after 20min of nothing happening…

I repeated the same procedure, without the “save as” option, just “Open in SNAP”… The collocated product is produced rather immediately. However, when I try to open the Optical it is ok, but when I try to open the Thermal, it got stuck like this:
snap64_2018-06-04_14-53-41

So actually it is not possible for me to work with Optical+Thermal products …
ps: I am using an intel i-7-7600 @ 2.9 GHz, with 16 GB RAM, rather a powerful machine for such a simple processing procedure!
Any help?

thanks!
Luca

#2

Hi Luca,
I am not sure about how the SNAP doing collocation internally.
But I suggest that you could subset your images before collocating them.

#3

The Task Manager shows that SNAP memory usage is only ~4GB so perhaps there’s something amiss with the VM parameters? @marpet @forman

#4

Hi bishun,
the subset might be a workaround for the meanwhile, but I don’t think it is the way to go…Sentinel-3 is been conceived as a medium/low resolution sensor with a large swadth and a high revisiting time, meaning that should be exploited to investigate/monitor global-scale processes…So actually the way to go is to exploit image composites/mosaicks of more than 1 scenes.
The problem I pointed here is related to a very basic, premiliminary operation (using only 1 scene) that should work smoothley if we want to exploit S3 (and other Sentinels) capabilities…
Looking forward for a solution :wink:
regards

#5

Hi Luca,
You are right and I am looking forward for it as well.

I think you could find the composite image in the Reduced Resolution product (i.e., OLCI_ERR) which is convenient to the global-scale processes.
Best wishes!

#6

Hi Luca,

probably you have enabled the pixel geo-coding for OLCI and/or SLSTR in the options. The is most likely the reason why it takes so long. If you switch back to tie-point geo-coding it should be faster but a bit less accurate.

We are working on improving the pixel-based geo-coding. But that not an easy task.

#7

Hi Marpet,

Just wanted to feedback on previous post…I have verified and all my reading options are disabled, so actually I was already using the “tie-point geo-coding” option and not the “per-pixel” one:

snap64_2018-06-13_16-27-14
snap64_2018-06-13_16-27-14.png752×660 31.8 KB

I have also improved the cache size assigned to SNAP under “Performance”, but anything changed, problem seems related to CPU rather than RAM, so I got the same problem again and again…
Any other idea?

regards
Luca