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

[Delfim Rego]

https://trac.osgeo.org/gdal/ticket/6514

On Sun, May 15, 2016 at 12:43 PM, Delfim Rego <delfimrego at gmail.com> wrote:
> 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