is your region within the SRTM coverage?
Oh wait, read the preview wrong sorry, it’s actually east of Guatemala city:
I believe it’s how the Subset Operator in GPT works.
If I run Subset separately with SNAP (not GPT), then Radiometric Calibration, then Terrain Correction, it works fine…
hm, I have often used the GPT to make subsets in batch mode actually.
Just to go sure: There is an option to mask out all water areas in the Terrain Correction, but you probably disabled it because your data is entirely over water, right?
Yep it is indeed disabled, I’m using an external DEM, which does work with the separate SNAP processes 
So I ran GPTs Subset (2 in the preview window) with:
Polygon ((-97.56358828861178267 14.96860616344341643, -97.56358828861178267 14.73100794671138303, -97.10260713307185654 14.73100794671138303, -97.10260713307185654 14.96860616344341643, -97.56358828861178267 14.96860616344341643))
And then ran SNAPs subset (3 in the preview window) with:
-97.56358828861178267 14.96860616344341643, -97.10260713307185654 14.73100794671138303
As you can see, SNAPs subset appears to be correct whereas GPTs still looks like it’s the full scene size. I assume that when it comes to Terrain Correction, the data is not mirroring the metadata?
If I import the WKT (Now converted to a Shapefile) into each product and plot them I get:
Raw Sentinel 1 GRD Product:
GPT Subset Product:
SNAP Subset Product:
It appears that GPTs data is correct, but it is not in the correct position, whereas SNAPs subset data is dead on.
1 Like
Interested to see what folks say! 
Hi Ciaran,
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?
2 Likes
that is a very interesting point!
I would love to see some benchmarking tests on execution times.
@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).
I will definitely check this though!
I’ll let you know how it goes!
1 Like
@gepo1 @ABraun unfortunately that doesn’t appear to be correct 
You can see that the processing was a lot quicker, 63 seconds (with the subset) vs ~20 minutes to process a whole scene.
Unfortunately when I import the WKT into the Subset dataset, it is still not located on the data.
I experience the same results with Copy Metadata true and false
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?)
Ah right. Well, it definitely speeds it up.
Still seems that Subset isn’t working as I’d expect it to
yes, your problem is still open. The developers are probably busy at the moment finalizing the SNAP 8 release, but I’ll keep an eye on it.
Okay thanks! Is there somewhere I can raise it as an actual issue? Or check whether it’s been raised before?
yes, here: https://senbox.atlassian.net/projects/SITBX/issues/?filter=allissues
But I am not sure if every one can submit an issue.
You can have a look if yours is already addressed. If not, please send me a short but clear summary which I can then enter as a new issue.