Running a simple graph to resample and subset a S2 scene (Read > Resample > Subset > Write) works only if the output is saved as BEAM-DIMAP. If I change the output to GeoTIFF-BigTIFF (or other format) I get an error message(“Error: [NodeId: Write] Product writer is unable to write this product as ‘GeoTIFF-BigTIFF’: Cannot write multisize products. Consider resampling the product first”). However, if I first run a resampling graph (Read > Resample > Write) with output saved as BEAM-DIMAP and then use this output as input to a subset graph (Read > Subset > Write) and save the second output as GeoTIFF-BigTIFF then it works fine.
I am using SNAP 5.0.1 and S2TBX 5.0.1. I did not experience this issue with SNAP 5.0.0/S2TBX 5.0.0.
Hi,
in snap 5.0.0 I met with this problem. I made a workaround with this method. First resampling to eg. 10m Second - subset from resampling image and third resampling from subset image and export to tiff/geotiff or Envi. In my case it works. Where did you find SNAP version 5.0.1. On ESA website is only version 5.0.0 released in December 2016.
yes I know. I thought that ESA released something new on website. I updated SNAP 5.0.1 and S2TBX 5.0.1 few days ago. I think resampling and subsetting S2 scene and saving as GeoTIFF-BigTIFF or Envi is a bug in this version because in last version I didnt’t have this problem.
When the behaviour changed then I think the problem is in the S2 reader. Because the writer for GeoTIFF-BigTIFF and Envi didn’t change recently.
What do you mean by “last version”? Do you mean 5.0 or 4.x?
I say about 5.0 version. Last time in SNAP appeared update plugin Sentinel 2 Toolbox kit module to version 5.0.1. I don’t remember exactly wich version was earlier but problem with subset didn’t appear. I have SNAP version 5.0.0 from December and this problem appear from 2-3 weeks. Mayby this problem is tied with update Sentinel 2 Toolbox kit module to version 5.0.1.
It seems that the cause is that in the last update we have added some methods to transfer some kinds of masks that were not copied before (for example, when doing subset in SNAP version 5.0 to a S2 product, there are no masks in the target product, but in version 5.0.1, they are available). The problem is that these masks are not properly managed by the subset operator (they are not cropped) and the final raster size is different, so it is not possible to write the product with a writer that does not support multisize product.
It seems that this bug lives on. At least I got the error message of “Cannot write multisize products” when trying to “BandSelect” bands B2, B3,B4,B8 and writing to GeoTIFF-BigTIFF. The situation seems to be the same both in versions 5.0.8 and 6.0.0.
Ciao
Yrjö
PS. The cloud masks in many cases seem to have a different bounding box compared to the image (in L1C products). I don’t understand this logic because the bounding box of a vector file does not eat disk space. Maybe this is somehow connected with the “multisize” thing.
I had exactly the same error with SNAP 5.0, though it used to work
…so after reading this, I installed SNAP 6.0 and the “resampling/subsetting/export to Geotiff” is working if I run my resample-Graph via the Graph Builder in the SNAP desktop application, but if I run the same Graph via commandline using gpt I still get the same error
Error: [NodeId: Write] Product writer is unable to write this product as ‘GeoTIFF-BigTIFF’: Cannot write multisize products. Consider resampling the product first.
I don’t get it, it should work no matter if you use the command line or the desktop application…?
I’m getting the same error using SNAP 8.0.0 on MacOS 12.1. Everything works fine while building the graph in the SNAP GUI, but if I load the graph using the batch tool I receive the “Error: [NodeId: Write] Product writer is unable to write this product as ‘GeoTIFF-BigTIFF’: Cannot write multisize products. Consider resampling the product first” error.
In my case this can be fixed by going to the “Write” tab > change output filetype to BEAM-DIMAP > change output filetype to GeoTIFF-BigTIFF. That said, this solution is still not particularly intuitive.
The error-message is reasonably informative, TIFF does not support bands of differing resolution in the same image. If you’d like to keep using TIFF you need to follow the instructions in the error.
While the error message does indeed make a true statement, my issue is that it does not actually apply to the current scenario since the graph process is not actually writing a multisize product but instead a subset and band-extracted one.
The below graph does work, but upon initial loading it still displays the error message:
Interesting. In general one should never do processing in other than the internal format, since strange things may happen. I think this is in the FAQ. Export to other formats should be done in a separate step/graph.
In this case I was under the impression that the data is its original format for the processing steps (“Subset” and “BandSelect”). To elaborate, the “Read” step is reading the data from S2A .zip files using the “SENTINEL-2-MSI-MultiRes-UTM32N” internal format, and only the output from the BandSelect step is then being written into GeoTIFF-BigTiff format in the Write step.
In other words, since the Write step is likely a key step in most graphs, why else would one have the option to write into a different format (non-internal) if it goes against best practices? Isn’t that one of the key features of graph builder/batch processing functions?
The writer is generic I believe and the guideline is to keep everything in BEAM-DIMAP during processing. I think we should add a warming to the operator GUI or what do you think @marpet?
Yes, it is okay to use different output formats.
What @mengdahl is referring to is that it is best to use BEAM-DIMAP as long as you want to use it for another processing step. Of course GeoTiff, NetCDF and others also work, but you will experience less issues with BEAM-DIMAP. But if the output of the graph is the final output of your processing then it is totally fine to use the format you woulke to use.
The issue here is actually that the error message is shown at all. The product after BandSelect is not multi-size anymore accroding to the report of @lusk.
My question is, my do you need the BandSelect operation, @lusk.
You can select the band already in the Subset operation.
If I leave out the BandSelect and select only bands of the same resolution in the Subset operation, I get no error.
But this also works if I select bands of the same resolution in the BandSelect.
What’s noteworthy is that the graph is only validated when switching tabs, or adding a new operator or when clicking on run.
If a parameter is changed the validation is not started immediately.
But this is for good reason. The validation can take quite some time depending on the data and the graph. Doing it with every paramter change would slow down the work with the Graph Builder.
And switching from one tab to another lets the error message disapear, eventhough nothing has changed and the error still persists. This might have caused confusion on your side @lusk.
For me the conclusion is that the error reporting in the Graph Builder could be improved. But it is actually working as intended.
Thanks for the clarification @marpet. To answer your question, my decision to include the BandSelect operation was really just due to my lack of understanding of exactly how the Subset operation works. I see now that, since one can select the bands they wish to extract during the Subset operation, the BandSelect operation was redundant.
But yes, my original reporting of this issue was more around confusion that came out of the error being displayed despite the processes having worked before. I see what you mean regarding the validation process, and overall my issue wasn’t a major one, more a minor inconvenience (which led me to this thread).
