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

Delfim Rego delfimrego at gmail.com
Sat May 14 02:14:41 PDT 2016


Julien,

The driver was tested only with GRD products. That's why it behaves so
badly with SLC.

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.

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.

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.

Thanks,
Delfim



On Fri, May 13, 2016 at 6:53 PM, Alessandro Amici <a.amici at bopen.eu> wrote:
>
> Even,
>
> furthermore subswaths typically have different pixel and line sizes.
>
> But the subswath level is easy bit of Sentinel-1 data, the real fun starts as you note that every individual tiff file is a collection of actual image segments (the bursts) interleaved with black stripes. The image segments actually overlaps by a small amount. As far as I can tell the current driver doesn't make any effort to recompose the swath image.
>
> As a matter of fact I'm not even sure what strategy can be used to make the Sentinel-1 data fit into the normal GDAL data model. Maybe treating bursts as image tiles?
>
> Cheers,
> Alessandro
>
>
> On Fri, 13 May 2016 at 15:54 Even Rouault <even.rouault at spatialys.com> wrote:
>>
>>
>> > This is obviously wrong, since pixels in each swath correspond to
>> > different observed ground points. In other word, there is no meaning in
>> > stacking the response of pixel (0,0) of swath one with pixel (0,0) of
>> > swath two, since they do not observe the same target landscape.
>> >
>> > I think the best would be to report at least the different swath as
>> > subdatasets (as done in S2 driver). For the sake of simplicity,
>> > polarisations too could be exposed as subdatasets.
>>
>> Julien,
>>
>> Looking quickly at the driver and with the observations you made, your
>> suggestions make sense to me. The swaths should defintely be in separate
>> subdatasets, and the GCP fetched from the appropriate annotation file. Whether
>> polarisations of the same swath are in different subdatasets is a matter of
>> taste (looking quickly in the code base I see the CPG driver also puts the
>> polarizations as different bands of the same dataset). Perhaps Delfim has some
>> comments?
>>
>> Even
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> 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


More information about the gdal-dev mailing list