BurstExtraction and GCPs
The BurstExtraction
application extracts a single burst from a Sentinel 1 SLC product and update the metadata accordingly. In particular, only the GCPs inside the burst are kept in the extracted image. However it appears that in some case the output burst contains no GCP. A SAR model needs at least one GCP as it serves as the initial guess in LineSampleToWorld
and LineSampleHeightToWorld
methods.
For example the product S1A_IW_SLC__1SDH_20211024T122521_20211024T122540_040261_04C531_CFB3
(available on Copernicus hub) has 6 bursts but the last burst contains no GCP. The last burst lies between lines 7539 and 9005, and between samples 0 and 20175. Some GCPs are very close to the burst, e.g. [line 7358 sample 13143 ] and [line 9023 sample 14154].
The bug can be reproduced with the lines:
otbcli_SARBurstExtraction -in /datas/S1Data/S1A_IW_SLC__1SDH_20211024T122521_20211024T122540_040261_04C531_CFB3.SAFE/measurement/s1a-iw1-slc-hh-20211024t122521-20211024t122538-040261-04c531-001.tiff -burstindex 5 -out /tmp/outburstextract.tif
to extract the burst, then
bin/otbcli_OrthoRectification -io.in /tmp/outburstextract.tif -io.out /tmp/outortho.tif -opt.gridspacing 10
will produce a segfault.
This happens on both OTB-7.4 and develop (8.0).
I don't know how frequent the problem occurs in S1 product, and I'm also not sure how we should handle it. A solution would be to keep all gcps in the extracted image (but this is not ideal because most GCP will not be used, the number of GCP is linked to the processing time of LineSampleToWorld
, as it is initialized by searching the closest GCP in the metadata). We could also only keep the GCPs within a margin around the burst of interest