[gdal-dev] Potential issue with Sentinel-1 SAFE driver

[Delfim Rego]

Hi Alessandro,

Thank you for your comments.

I also use SLC products for running detection algorithms, but for that
I just access xml metadata and measurement data directly using the
GTiff driver.

Nevertheless, the SAFE driver should open all product types for as
most usecases as possible, either to perform a simple gdalwarp or to
read the data and execute an algorithm.

With that in mind, this is my idea for the subdataset acess:

$ gdalinfo S1A_PROD.SAFE
...
Subdatasets:
  SUBDATASET_1_NAME=SENTINEL1_DS:S1A_PROD.SAFE:EW1:VH
  SUBDATASET_2_NAME=SENTINEL1_DS:S1A_PROD.SAFE:EW2:VV
  SUBDATASET_3_NAME=SENTINEL1_DS:S1A_PROD.SAFE:EW3:VH
  SUBDATASET_4_NAME=SENTINEL1_DS:S1A_PROD.SAFE:EW4:VV
  SUBDATASET_5_NAME=SENTINEL1_DS:S1A_PROD.SAFE:EW5:VH
  SUBDATASET_6_NAME=SENTINEL1_DS:S1A_PROD.SAFE:EW1:VV
  SUBDATASET_7_NAME=SENTINEL1_DS:S1A_PROD.SAFE:EW2:VH
  SUBDATASET_8_NAME=SENTINEL1_DS:S1A_PROD.SAFE:EW3:VV
  SUBDATASET_9_NAME=SENTINEL1_DS:S1A_PROD.SAFE:EW4:VH
  SUBDATASET_10_NAME=SENTINEL1_DS:S1A_PROD.SAFE:EW5:VV
Band 1 Block=256x16 Type=CInt16, ColorInterp=Undefined
  Metadata:
    POLARISATION=VH
    SWATH=EW1
Band 2 Block=256x16 Type=CInt16, ColorInterp=Undefined
  Metadata:
    POLARISATION=VV
    SWATH=EW1

$ gdalinfo SENTINEL1_DS:S1A_PROD.SAFE:EW3:VV
...
Band 1 Block=256x16 Type=CInt16, ColorInterp=Undefined
  Metadata:
    POLARISATION=VV
    SWATH=EW3

$ gdalinfo SENTINEL1_DS:S1A_PROD.SAFE:EW3
...
Band 1 Block=256x16 Type=CInt16, ColorInterp=Undefined
  Metadata:
    POLARISATION=VH
    SWATH=EW3
Band 2 Block=256x16 Type=CInt16, ColorInterp=Undefined
  Metadata:
    POLARISATION=VV
    SWATH=EW3


Cheers,
Delfim



On Sat, May 14, 2016 at 9:28 AM, Alessandro Amici <a.amici at bopen.eu> wrote:
> Delfim,
>
> as I've been mostly lurking gdal-dev up to now, first a brief intro of
> myself: I'm a long time GDAL user, I contribute a bit to it and even had
> commit access back in 2003/2004. I've been involved in writing a driver for
> Sentinel-1 SLC data for a customer first and then reimplemented a subset of
> the functionalities for an internal project, so I have some hands on
> experience.
>
> On Sat, 14 May 2016 at 10:40 Delfim Rego <delfimrego at gmail.com> wrote:
>>
>> The driver was tested only with GRD products. That's why it behaves so
>> badly with SLC.
>
>
> Yep! If you didn't tackle SLC imagery yet, do not underestimate how weird
> and badly documented it is!
>
> Points to take into account:
>
> 1. a lot of metadata are different for different subswaths, they even have
> different sizes typically. Recomposing different subswaths into a single
> image will make working with metadata a mess, just think of the GCP! I
> strongly suggest treating subswatshs as subdatasets in GDAL.
>
> 2. polarizations within a subswath on the other hand share all metadata and
> image structure, I don't see why they should not be treated as bands. This
> is what we did for our customer, but this could be a matter of taste though.
>
> 3. the internal structure of the single SLC subswath is where the real mess
> starts. The tiff in the measurement folder are not actual images, but are a
> container of tiles with black borders separating them. In the metadata there
> are all the information on how to cut the non overlapping tiles and how to
> rebuild them into a standard subswath image. Furthermore some metadata, like
> the GCP info are given in a weird and barely documented format. I don't know
> all the details as a colleague worked on that, but I think you need to
> process the GCP line/sample numbers for the recomposed image.
>
>> Let's look at the possible solutions and I would like your comments:
>>
>> Option 1) the driver provides polarizations as bands also on SLC products.
>> In this case, each band would represent a polarization and would aggregate
>> and reconstruct all swaths based on the GCPs. The reconstruction would need
>> some processing, and prevents the user to use a single swath.
>>
>
> I'm strongly against that, it is a lot of work and representing the metadata
> will be inevitably a mess.
>
>>
>> Option 2) the driver provides all measurements as subdatasets. In Julien
>> example it would create 6 subdatasets, one for each polarisation and swath.
>> This option would add flexibility to the user, since it would be possible to
>> select individual swaths.
>
>
> This would not be my preferred option as a user, but close enough.
>
>> Option 3) Using both. When no subdatasets are selected, the driver
>> provides an assembled dataset  (each band representing a polarization).
>> However, the user could also select each individual measurement as
>> subdatasets.
>
>
> IMO no, same as option 1.
>
> Option 4: subswaths are different subdatasets each with polarizations as
> bands.
>
> This is my preferred approach and we have implemented it in practice twice
> (outside of GDAL).
>
> Hope this helps,
> Alessandro
>
> --
> Alessandro Amici <a.amici at bopen.eu>
> CTO at B-Open Solutions - http://www.bopen.eu/
> Viale Palmiro Togliatti, 1639 - 00155 Roma - tel: +39 06 8370 8269