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 <[email protected]> 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 <[email protected]> CTO at B-Open Solutions - http://www.bopen.eu/ Viale Palmiro Togliatti, 1639 - 00155 Roma - tel: +39 06 8370 8269
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
