Subset image only converts values to NaNs, does not actually subset the image

Yes, this sounds like an issue with the batch processing.
I’ve created an issue for it: [SNAP-1366] Using Subset in Batch Processing results are misplaced

@giangnv When you talk about batch processing your talking about the one in the GUI. Not batch processing from the command line, right?
But this might be a way to go for you. You can use the created graph also from the command line.
In our wiki we have a guide how to do batch processing on the command line.
Bulk Processing with GPT - SNAP Wiki

1 Like

Thanks @marpet and @ABraun for your consideration and suggestion.
Yes, I am using the GUI Batch processing.

Dear @ABraun,

This is the sample ID of two SAR scenes and the shapefile of the study area.

S1A_IW_GRDH_1SDV_20201015T225152_20201015T225217_034813_040EBA_9C13
S1A_IW_GRDH_1SDV_20201018T110532_20201018T110557_034850_041018_E503

Study area_fixed_topo.rar (10.9 KB)

I downloaded the files and tested:

  1. Apply Orbit File
  2. Radiometric calibration
  3. Import the vector
  4. Mask the product based on the vector
  5. Terrain correction

With the graph builder:

Manually in the GUI
grafik

Results after terrain correction (and -reimporting the shapefile because it was not preserved in the TC step)

graph processing tool:

manually (GUI)

I can’t replicate your problem, the import works fine, the masking is alright, and the geocoding is correct for both the rasters and the vector.

Thanks @ABraun for your testing.

It worked for me if I ran those steps manually. This process took hours.

It did not work properly when I ran with the Subset function included in the Batch processing. In this case, I used the same Batch I made last year for historical SAR images. I tried on 2 computers to check whether there was a problem with the system file. I found this is strange because this Batch worked last year.

This is the geo-coordinate for the subset. Would you mind try with this in a whole batch for both scenes:

POLYGON ((105.47077178955078 18.774812698364258, 106.1618423461914 18.774812698364258, 106.1618423461914 18.026975631713867, 105.47077178955078 18.026975631713867, 105.47077178955078 18.774812698364258))

Big thanks,

I integrated your subset like this

Still, no error.
Maybe it is worth re-creating the graph, testing step by step if the output is alright before you add more operators.

Dear @ABraun,

Thank you for your attempt.
Of course, I did make a new Batch (Graph) after each testing step which is similar to your suggestion. The SNAP program run much faster in Batch process rather than each single step. However, the error still existed.
Really don’t know why and how it happened.

Dear @ABraun,

Could you do me a favor? Once you have time, please download the remaining SAR scene and run the Graph to check whether the Batch process would show consistent results from the two swaths.

S1A_IW_GRDH_1SDV_20201015T225152_20201015T225217_034813_040EBA_9C13
S1A_IW_GRDH_1SDV_20201018T110532_20201018T110557_034850_041018_E503

1 Like

I made the new Graphs, and I had no clue for these error messages.
There might be something happened with the system. :pensive:

Please uncheck the “Use SRTM 3Sec“ option

1 Like

Thanks @ABraun,
Could you explain how the option “Use SRTM 3sec” would affect the results?
Besides, what would be recommended DEM to use in the Terrain correction operation? I used to use SRTM 3sec, but there are some other DEM options too. What if the more detailed DEM is selected? And whether all of these DEMs are available/covers worldwide?

Actually, this option is only required if you want to mask sea areas based on the DEM. But as you use a vector for masking, the SRTM will not be needed. That’s why I suggested to disable this option.

SRTM is only available between 60° North and South. If your area is within, you can use it - SRTM 1Sec has a higher resolution and is therefore more accurate. The other ones are of lower resolution.

1 Like