First Valid Line / Pixel

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.


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.

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?


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

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?

Have you tried building the s1tbx from source? See

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.

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