INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: GDAL 2.4.1 found on system. JNI driver will be used.
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: Installed GDAL 2.4.1 set to be used by SNAP.
INFO: org.esa.snap.core.util.EngineVersionCheckActivator: Please check regularly for new updates for the best SNAP experience.
INFO: org.esa.s2tbx.dataio.gdal.GDALVersion: Installed GDAL 2.4.1 set to be used by SNAP.
Executing processing graph
INFO: org.hsqldb.persist.Logger: dataFileCache open start
…10%…20%…30%…40%…50%…60%…70%…80%…90% done.
The geotiff contains 67 bands. Many of them are empty and after inspection, I am guessing that the processed SLSTR data is in the last band.
This issue occurred with SNAP7, remained when updating to SNAP8 and I may have seen similar outputs when processing OLCI scenes after similar geotiff generation.
You shouldn’t have to guess at the contents of a band. BEAM Dimap or NETCDF-CF should preserve more of the metadata than GeoTIFF’s, and can be imported to many (current) 3rd party applications.
It could be helpful to know if the problem is limited to GeoTIFF’s.
Thank you for your quick response.
The content of band 67 in the output geotiff is indeed slightly different (different shape of histograms) than what I get when calculating S1 reflectances in SNAP.
But before we go into how these rasters differ, I’d be interested to know if it is normal that I get 67 bands as output and if the problem is reproducible by others.
After replicating the issue on different machines, I can confirm that this problem appears with the installation of SNAP8. It occurs with both SLSTR and OLCI data when using Rad2Refl -> Reproject -> BandSelect -> Write as geotiff.
The additional bands seem to be tie-point grids of auxiliary data.
I can for example reduce the number of bands outputed by changing
However that makes me unable to filter the output of Rad2Refl with quality flags or extract auxiliary information (altitude, ozone… etc) from the same node.
It seems that there has been a change, in SNAP8, in the way these auxiliary data are dealt with when written as geotiffs. I hope an easy fix is possible.
Regarding the "Error: SPI not found for operator 'BandSelect’ problem.
Was the S1TBX installed when this occurred?
Because this operator is provided by this toolbox.
Can you give a bit more details? I thought Subset was to clip a product for a given area.
Which parameter should I use to keep the full scene? and to leave the masks out?
Since I need some of the masks for BandMath before I write each band to geotiff, can I do something like:
Read > Reproject > BandMath (where I use the masks to process a given band) > Subset (to drop the masks) > Write
Subset can do both regional subset and band subset, too.
You can use sourceBands to define the bands to include and tiePointGridNames for tie-point grids.
Leave region and geoRegion empty.
See also help on gpt:
Thanks!
I manage to extract the desired band without the masks. But it seems that some of the masks are applied to the band automatically. I think it is the flag called “quality_flags_duplicated”.
How can I prevent this behaviour from happening?
I think your image does not show the OZA band. It seems there is a coastline visible. Which should not be the case for the observation zenith angle.
I’ve used your graph and got the result on the right. No NaN values visisble.
Have you run the graph through gpt or using SNAP’s graph builder?
When I run the previous graph using GPT, I get the output above, with NaN.
When I load the graph into SNAP’s graph builder, I have an error related to the EPSG 3413 CRS: “This “AxisDirection” object is too complex for WKT syntax”
But using GPT and either i) Reproject with EPSG 4326; or ii) no Reproject (feeding directly Rad2Refl to Subset), still replaces many pixels by NaNs as illustrated above.
Ah, that’s good.
Actually, it is still valid, but there are currently issues at high latitudes. We are already working on it. That’s why it wasn’t visible in my scene. It wasn’t located so far in the north.
The location accuracy might be a bit lower now in your case. But I guess still good enough.
ow the tie-points are used.
Multiple bands in outputs when using BandSelect
This is the expected behaviour of BandSelect. It outputs masks and flags as extra bands.
Use Subset instead.
Example:
NaN in outputs after subset
Using pixel geocoding replaces some pixels by NaNs. This appears only when using the option:
" -Ds3tbx.reader.olci.pixelGeoCoding=true" in gpt
Error when reprojecting in EPSG 3413 in SNAP’s graphbuilder