Launch Watch · Satellite
Published
Sentinel-1 pairing: two descending scenes can still use different tracks
Audit six Paris Sentinel-1 RTC records: every adjacent-date pair changes track, including one pair with matching descending labels. Three same-track pairs remain.
In a six-scene Sentinel-1 catalog sample over central Paris, all five chronologically adjacent pairs switch relative orbit. Four also switch between ascending and descending. The fifth is the useful trap: 11 April and 16 April 2024 are both descending, but belong to relative orbits 110 and 8.
A direction-only filter would keep that pair. It would not make the viewing track the same. This small audit shows how to expose the mismatch before calculating an image difference. It does not claim that a radar brightness change was measured, or that every cross-track comparison is scientifically impossible.
Start with the six actual catalog records
We queried the Planetary Computer Sentinel-1 RTC catalog with a bounding box of 2.34–2.36° E and 48.84–48.86° N, date bounds 2024-04-01/2024-04-30, and a limit of 100. The saved response contains six items and no next-page link. We then checked whether each footprint polygon covers the test point, 2.35° E, 48.85° N. All six do.
Every item is Sentinel-1A, IW mode, VV/VH polarization and right-looking. The orbit metadata still separates them into three tracks. Dates and times below use each item’s STAC datetime, not the first timestamp embedded in its filename.
| Acquisition date (UTC) | Relative orbit | Orbit direction |
|---|---|---|
| 2024-04-04 06:08:00 | 8 | Descending |
| 2024-04-07 17:41:05 | 59 | Ascending |
| 2024-04-11 05:59:48 | 110 | Descending |
| 2024-04-16 06:07:59 | 8 | Descending |
| 2024-04-19 17:41:05 | 59 | Ascending |
| 2024-04-23 05:59:50 | 110 | Descending |
The nearest-next-date rule fails this metadata check
Sort all six records by date and pair each one with the next record. The resulting gaps look attractive: about 3.48, 3.51, 5.01, 3.48 and 3.51 days. But each short interval joins different relative orbits.
| April dates | Interval (days) | Relative orbit | Same direction? |
|---|---|---|---|
| 04 → 07 | 3.481 | 8 → 59 | No |
| 07 → 11 | 3.513 | 59 → 110 | No |
| 11 → 16 | 5.006 | 110 → 8 | Yes, descending |
| 16 → 19 | 3.481 | 8 → 59 | No |
| 19 → 23 | 3.513 | 59 → 110 | No |
The 11→16 April pair deserves a separate check. Its roughly five-day gap and descending direction may look consistent enough in a simple spreadsheet. The relative-orbit fields reveal the remaining difference: 110→8. A filter that checks only the direction does not control the track.
That finding is a property of this retrieved sample. It is not a general Sentinel-1 revisit estimate or a count of all acquisitions over Paris. “No next page” means the saved query response was exhausted; it does not certify mission-wide completeness.
Group first, then construct the pairs
For a conservative same-track comparison, group the records by relative orbit within the already matched platform, mode and polarization selection. Sort by time inside each group. Here that gives three candidate pairs:
- Track 8, descending: 4→16 April, approximately 12 days.
- Track 59, ascending: 7→19 April, approximately 12 days.
- Track 110, descending: 11→23 April, approximately 12 days.
The stored datetimes give intervals of 11.9999994, 12.0000033 and 12.0000140 days respectively. Those extra digits preserve the catalog arithmetic; “about 12 days” is the useful reading. This result also explains why choosing the smallest time gap and choosing a same-track pair are different operations.
Google’s Sentinel-1 processing guide recommends selecting a homogeneous subset using metadata such as polarization, instrument mode and orbit direction. Our catalog example adds a concrete reason to inspect relative orbit as well. The guide describes Earth Engine processing; it is not evidence that these Planetary Computer RTC files use Earth Engine’s processing chain.
A matched track is a starting condition
After the metadata audit, inspect the actual rasters. Footprint coverage alone does not prove that the chosen point has valid backscatter in every product. A candidate pair still needs compatible units and polarization, valid-data masks, registration checks and a treatment of incidence angle and terrain. Processing provenance, weather and the target’s state also matter to the interpretation.
Cross-track observations can be useful when the analysis explicitly accounts for their different geometry. What this test rejects is the shortcut of treating the next date, or two matching direction labels, as proof of like-for-like sampling. It does not supply a universal acceptance threshold for radar change detection.
These are RTC intensity products. No phase data are analyzed here, and these files should not be described as an interferometric pair for an InSAR displacement calculation.
Inspect every record and reproduce the pairing
The catalog and footprint extract (CSV) contains the six item identifiers, common instrument fields, orbit fields, item links and polygons in well-known text (WKT). Test the point 2.35° E, 48.85° N against each footprint, sort the covered items by datetime, and compare relative orbit and direction for consecutive records. Our independent reproduction used ray casting, separate from the original extraction’s Shapely coverage check.
Download the six-scene CSV, five adjacent-date pairs or three same-track pairs. To build the latter, group the same metadata selection by relative orbit and pair records inside each group. No radar image is needed to repeat this metadata audit.
Sources and scope
- The exact STAC query and the six item links above provide the empirical records.
- Planetary Computer RTC collection metadata identifies the collection and CC BY 4.0 license.
- Earth Engine Sentinel-1 guide supplies the general metadata-filtering context.
- Copernicus Sentinel legal notice supplies the underlying data-use and attribution terms.
Catalog snapshot and sources checked 4 October 2026. This is an original metadata-derived chart and pair-selection audit, with no reused radar image or basemap. The answer established here is which retrieved records share a track; whether they reveal a real surface change remains a separate analysis.