First Valid Line / Pixel

Microwave Toolbox
1

A typical sentinel-1 (TOPS) image comes with a couple of xml files. For example: S1A_IW_SLC__1SDV_20151006T172451_20151006T172518_008035_00B3FD_93F1.SAFE/annotation/s1a-iw1-slc-vv-20151006t172452-20151006t172517-008035-00b3fd-004.xml

Both the first valid line and pixel can be extracted from the <firstValidSample> element:

<firstValidSample count="1499">-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 906 906 906 
... 
906 906 906 906 906 906 906 906 906 906 906 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1</firstValidSample>

Where can I find this information for the deburst/merged product (SLC or interferogram)? In the corresponding .dim file, I’ve only been able to find the time to first pixel (from <slantRangeTime>) and the first line time (from <first_line_time>). However, there’s no trace of the first valid pixel/line.

Esteban
SkyGeo

2

The information is for the burst data. After deburst and merge this information is removed as it is in the GRDs. Any non-valid pixels are set as no-data-value.

3

Hi Luis,

Thanks for your reply. The reason I’m asking is because we are getting lat/lon shifts when geocoding the merged product (SLC). If I interpret the first range sample as being 906 (instead of 1), these shifts disappear. Could you please let us know if you’re having similar issues?

Esteban
SkyGeo

4

The problem has been fixed and it should be in the next release. Thank you for reporting the problem.

5

I am experiencing the problem that one subswath of an S1 product is not geolocated properly (about 4km shift in range) for a specific product (S1A_IW_SLC__1SDV_20151125T164618_20151125T164645_008763_00C7CB_0C97), while the other subswaths are correct.Could this, in your opinion, be related to the bug discussed, and reported fixed, in this topic?

And if so, is there a rough estimation when the next (Beta) release will be?

6

Have you tried building the s1tbx from source? See README.md

7

Yes we do compile from source, but it would be nice to have some indication if there is a chance of solving it this way. Especially since we have processed many S1 products without problems before and we need to do many test when switching to a newer version again.

9

I geocoded the image again and the range shift is solved. I still see a slight azimuth shift though. Maybe another timing issue?