<div dir="ltr">Delfim,<br><br>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.<div><br><div class="gmail_quote"><div dir="ltr">On Sat, 14 May 2016 at 10:40 Delfim Rego <<a href="mailto:delfimrego@gmail.com">delfimrego@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>The driver was tested only with GRD products. That's why it behaves so badly with SLC.<br></div></div></div></div></blockquote><div><br></div><div>Yep! If you didn't tackle SLC imagery yet, do not underestimate how weird and badly documented it is!</div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Points to take into account:</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">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.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">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.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">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 </span>colleague<span style="line-height:1.5"> worked on that, but I think you need to process the GCP line/sample numbers for the recomposed image.</span></div><div><span style="line-height:1.5"><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>Let's look at the possible solutions and I would like your comments:<br><br></div>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.<br><br></div></div></blockquote><div><br></div><div>I'm strongly against that, it is a lot of work and representing the metadata will be inevitably a mess.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>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.<br></div></div></blockquote><div> </div><div>This would not be my preferred option as a user, but close enough.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div></div></blockquote><div><br></div><div>IMO no, same as option 1. </div><div><br></div><div>Option 4: subswaths are different subdatasets each with polarizations as bands.</div><div><br></div><div>This is my preferred approach and we have implemented it in practice twice (outside of GDAL).</div><div><br></div><div>Hope this helps,</div><div>Alessandro</div><div><br></div></div></div></div><div dir="ltr">-- <br></div><div dir="ltr"><span style="line-height:19.5px">Alessandro Amici <</span><a href="mailto:a.amici@bopen.eu" style="line-height:19.5px">a.amici@bopen.eu</a><span style="line-height:19.5px">></span><br style="line-height:19.5px"><span style="line-height:19.5px">CTO at B-Open Solutions - </span><a href="http://www.bopen.eu/" rel="noreferrer" style="line-height:19.5px">http://www.bopen.eu/</a><br style="line-height:19.5px"><span style="line-height:19.5px">Viale Palmiro Togliatti, 1639 - 00155 Roma - tel: +39 06 8370 8269</span><br></div>