On the presence of 'Leap Second' in orbital data records

[pmar]

Just dumping this note here, not to forget, and because it might be useful to someone else.

---

Recently I introduces series of fixes for the orbit interpolation in NEST. While working on these fixes, and studying the getorb package, I looked into a potential issue of handling leap seconds in orbital records and their impact in SAR/InSAR applications.

Not accounting for leap seconds in orbit handling, can introduce systematic errors in geo-localisation and other operations that depend on the orbital information, eg, flat earth removal, etc. Specifically with geocoding, not taking the leap second into account would result to about 7 km alongtrack geocoding error on ground; issues mentioned here.

The check for the leap second is straightforward:

(1) Check for the presence of the leap second in the orbital arc:

(first_time - last_time)/n_records == pre_defined_arc_length

(2) If leap second present, determine where exactly +1 second was introduced (this can be also hardcoded, since this information is well known)

time_record(i+1) - time_record(i) != delta_defined

(3) Step 2, gives index where update happened, and use this index to compare index of interpolated point and other points used in the interpolation, and depending on this increase time_stamps of points used in the interpolation. Otherwise interpolation errors, because not equidistantly sampled data can occur.

---

Very nice, I implemented this. With lot's of ifs, thanks to NEST implementation that interpolates orbits point per point, and not as a vector. Tested everything on the synthetic, and then decided to further validate on the real data.

However, it turned out that there is no data, that would be potentially affected by this, available at all. I used EOLI tool to query the database, see the screenshot.

So, no SAR data available for any of ERS 1, ERS 2, and Envisat sensors. Strange, the polar guys must have been acquiring at least data on the leap second New Years? Still, no data. Perhaps ESA removed any of images tagged 'potentially problematic' from the archive,

Hm, problem solved? For SAR applications, sort of. Therefore, I decided not to push these patches, and not to pollute code with lots of ifs that will never trigger.

Thanks for listening...

Update: ScanSAR data that is affected by leap second is in the archive. Follow updates.

[pmar]

Ah of course ScanSAR data! I was thinking too Stripmap InSAR here. Seems like that there is data in the archive that is affected but this issue, still it is only one scene.

[pmar]

Any of these images might be hit by this leap second thing.

2008/20081231/ASA_WSM_1PNPDE20081231_232519_000000732075_00130_35755_8761.N1
2008/20081231/ASA_WSM_1PNPDE20081231_233528_000002452075_00130_35755_8871.N1
2009/20090101/ASA_WSM_1PNPDE20090101_001317_000000672075_00131_35756_8877.N1
2009/20090101/ASA_WSM_1PNPDE20090101_001825_000003672075_00131_35756_9033.N1