https://trac.osgeo.org/gdal/ticket/6514
On Sun, May 15, 2016 at 12:43 PM, Delfim Rego <delfimr...@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.am...@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 <delfimr...@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.am...@bopen.eu> >> CTO at B-Open Solutions - http://www.bopen.eu/ >> Viale Palmiro Togliatti, 1639 - 00155 Roma - tel: +39 06 8370 8269 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev