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

[Alessandro Amici]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160514/14b088e6/attachment.html>