<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 14/05/2016 11:28, Alessandro Amici a
écrit :<br>
</div>
<blockquote
cite="mid:CAF0=-Tdu3PSTEcsu3ZstFw-o9zbgb=JeVhVGzo9xuvuh8G9mqw@mail.gmail.com"
type="cite"><span style="line-height:1.5">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></blockquote>
<br>
Thanks a lot for all those comments. I just want to give my opinion
on the SLC products with bursts (not all the acquisition modes
produce this I think). In such products, you have black separator
lines (and it is quite funny to note that GCPs from metadata
actually fall within those lines !) and acquisition time overlap
between bursts. IMHO, how to deal with those product is the advanced
SAR user problem, and gdal should not do anything about it. Trying
to workaround the problem could even prevent users from doing things
with those data : for instance, in the overlap area you have two
independent measurements of the backscatter for the corresponding
cell, which is surely an interesting information to use.<br>
<br>
Julien<br>
<pre class="moz-signature" cols="72">--
Julien MICHEL
CNES - DCT/SI/AP</pre>
</body>
</html>