i came across similar problems in the past.
For me it has always worked when putting the subset operator at the end of the graph just before the write-node. This also seems to affect the previous steps, i.e. the subset seems to be applied from the beginning on, as processing time is much shorter than when processing the whole scene.
Have you tried that already?
@gepo1 I have not! I’d always assumed it would be applied after the other steps therefore making the addition of it pretty useless in my case (where I wont need the whole image).
to my understanding, the difference which @gepo1 pointed out was the position of the subset within the graph, not if it is used at all.
I would have placed it at the beginning based on my logic that it reduces processing time but obviously at the end is an option too.
As I understood him, even if the subset operator is placed at the end, it will reduce the processing time (even more than at the beginning?)
Issue:
Subset Operator in GPT does not correctly geo-reference products whereas the SNAP Subset Operator via the GUI does.
When importing the GeoRegion as a Shapefile (produced from the WKT), the GeoRegion overlaps the products subset using the SNAP Subset Operator, it does not overlap those subset with GPT.
Final product should be the result of Subsetting, Radiometric Calibration (Intensity_VH), and Terrain Correction
This topic (possibly different reasons) still seems to be open in SNAP 8.0.8. Is GPT used also when using the graph builder in SNAP?
Use of the subset module (I put it in the beginning of my graph though) subsets a different area compared to what the coordinates (as given by other software, e.g., QGIS) actually cover, and the geocoding (terrain correction) is incorrect - seriously off (several kilometers in my case, possibly related to the subsetting properties).
Hi,
I would like to revive this, I have the same issue on SNAP 10 with S1SLC coregistered products.
Subset in GPT is not working, it complains that it has no source (whereas it does)
Subset in the GUI works as expected.
Both polygon and pixel extent show the issue.