And which would be the expression for S1A?
Thanks
S1-A: Relative Orbit Number = mod (Absolute Orbit Number orbit - 73, 175) + 1
S1-B: Relative Orbit Number = mod (Absolute Orbit Number orbit - 27, 175) + 1
4 Likes
Thank you very much for your answer. In the meantime I have found out juggling around with the numbers of the example.
@spatialtrail and @peter.meadows the tiles of Sentinel-1 having different extents are resulting in the same relative orbit of 92.
S1A_IW_GRDH_1SDV_20191103T003105_20191103T003130_029739_03639C_FB5C.wkt and its Extent is
78.80412 14.89078 81.42895 16.83671
S1A_IW_GRDH_1SDV_20200805T002754_20200805T002819_033764_03E9E5_716C.wkt and its Extent is
81.08151 26.63921 83.886 28.56222
Am I doing something wrong here?
Thanks in advance
Sentinel-1 A & B are in a repeat period of 12 days and 175 orbits. The relative orbit is the orbit number within each repeat period with values from 1 to 175. So each relative orbit covers a whole orbit and thus covers (almost) all latitude ranges.
Your two images are indeed from the same relative orbit since the difference in absolute orbit number is a multiple of 175, i.e. (33764-29739)/175 = 23 exactly.
To ensure two images with the same relative orbit cover the same region of the ground, the two acquisition times should be very similar (within a few seconds). In your case there is just over 3 minutes between the two images (15s corresponds to approx. 100km along track). You will need to pick a pair of products with much closer acquisition times for them to cover the same region on the ground.
1 Like
Thanks for the detailed explanation @peter.meadows. The problem I am facing is I want to identify the start and end dates of data already available for a farm in my computer (downloaded).
In Sentinel#2 the search is based on the tile ID. In case of Sentinel#1 how do I find the data available (already available) based on the relative path for a tile.
Thanks
I suggest you use the Copernicus Open Access Hub at https://scihub.copernicus.eu/dhus/#/home. You will be able to find your location and which products have been acquired over that location.
Hi, I have searched a lot the forum and not found an answer to my question, I think you could probably solve my problem.
In the kmz files from SAR-MPC Test Datasets (sar-mpc.eu/test-data-sets) all S-1 bursts are identified thorugh an āabsolute burst IDā, a number from 1 to 375887. The shapefile also reports the ārelative orbitā number, however I cannot find a way to identify the corresponding āsliceā number in the orbit, which is fundamental to be able to select, starting from an absolute burst ID, several S-1 products over the same location! Also, it would be amazing to be able to recover, the local burst ID (number from 1 to 9) starting from the same absolute burst ID, which I think is a mod9 operation, with some offset that is unknown to me.
If youlike please contact me at: mazanetti@fbk.eu
Can you help me?
Massimo
See section 9.25 about burst ID calculation:
Thank you, this is interesting. I tried with one image but the formula seems to not work. To make sure I am using the correct values of the parameters:
t_b mid-burst sensing time: I got this information from swath file ./annotation/s1ā¦xml, in the azimuthAnxTime field (it is the only temporal parameter in the burst data) is it correct?
t_ANX anx time of current orbit: I got this information from ./manifest.safe file, here I have two fields: s1:startTimeANX and s1:stopTimeANX, both do not work correctlyā¦
Can you suggest where I am wrong?
I can only read the document where they refer to the L0 manifest file, perhaps @ghajduch could advise how to do the calculation from L1 metadata?
If you are only looking for relative orbit number from the filename, you can just figure out any ascending node for track 1 starts for each of the satellites with a few searches - you know that this needs to be around 18:00 UTC. After that, its just the time step between orbit numbers is just 12 days / 175 orbits. You can just use filenames and these reference times to figure this out.
Hi,
The kmz we provide are representative of any cycle.
As such the kmz does not refer to an āabsolute burst IDā, but to a burst ID, which is actually a relative one within a cycle. Their purpose is exactly to provide a bijection between beam (for instance IW1) + burst id and a geographic location.
We provide a well two sqlite databases (one for IW and one for EW) providing the same type of information.
In both case, the relative orbit number is only provided for convenience, for instance to filter the huge list of burst id, or from a given burst ID, to filter a list of products by the corresponding relative orbit number. The burst id values are consecutive from one relative orbit to another (for the same sub swath).
In the S1 products, we provide both the burst id (the one comparable to the burst id map), and the absolute burst id, which is a unique identifier of a burst. One cannot directly compute the burst id from the absolute burst id as a cycle is not an exact multiple of burst duration (neither for IW, nor for EW)
In S1 terminology, a āsliceā is a part of a data take. A data take is a continuous acquisition of data in the same acquisition mode (EW or IW or ā¦) and the same polarisation configuration. For a same relative orbit, the location of start or stop of the data take may change from one cycle to another depending on the mission planning (even if not changing completely). Thus there is no way to perform absolute prediction of slice number from burst id, acquisition time or something else.
A slice of (EW or IW) is composed of multiple bursts acquired from multiple subswath. As the start of a datatake may be changing from one cycle to another, a given burst can be part of slices with different coverages. Thatās the reason why we do not provide āsliceā id, but burst id.
I donāt understand your point about ālocal burst IDā.
1 Like
The burst data in the ./annotation/s1ā¦xml does not contain one, but at least three temporal parameters:
azimuthTime as an date in UTC
azimuthAnxTime as a time since last ANX
sensingTime as a date in UTC
The azimuthAnxTime shall correspond to tb - tAnx in the formula (that is time since last ANX). However I am not sure if the azimuthAnxTime refer to the start, center, end of the burst.
The relative orbit number is provided in the manifest, both for the start, and stop of the slice (may not be the same for products acquired over ascending node crossing the equator).
There was some issues with the annotation of startANX and stopANX in series of L0 products. You can refer to the corresponding Quality Disclaimers 79 and 80 (Sentinel-1 MPC Quality Disclaimer #79 and Sentinel-1 MPC Quality Disclaimer #80).
This was impacting the L1 products in cascade for ANX annotation and for burst ID. You can refer to Quality disclaimers 77 and 78 (Sentinel-1 MPC Quality Disclaimer #77 and Sentinel-1 MPC Quality Disclaimer #78). But this is now solved.
The computation of burst ID may be affected as well by inaccuracy of annotation of ANX time for some L0 products. We are identifying themā¦ but this is a very long process.
Hi @ghajduch , thank you for your information. By ālocal burst IDā I mean the number between 1 and 9 that is required in input to the TOPS Split function in SNAPā¦ To me is very important to understand if there is a deterministic way to relate burst ID with this number (this is to programmatically trigger the TOPS Split function). I fear it is notā¦
Hi,
Then this is more a question about SNAP usage than on the content of the data.
Are you referring to Python S1-TOPS-SPLIT Analyzer
If so, this may be ājustā about adding the relative burst ID to the list of information extracted by the tool, and/or placing an entry value to filter by relative burst id.
The source code being accessible here GitHub - pbrotoisworo/s1-tops-split-analyzer: Python interface for visualizing and extracting Sentinel-1 TOPS SPLIT data that is used in ESA SNAP Software you can implement this as well.
Maybe @panjibrotoisworo can help ?
I am not referring to any Python script, just the SNAP function available in the SNAP software:
Radar >> Sentinel-1 TOPS >> S-1 TOPS Split
It is a bit crazy that there is no way to trigger this function without opening the image and check MANUALLY which is the number of the burst (counting them from 1 to 9), instead of just reading some info in the metadata beforehand.
For the data after IPF 3.5.x it is possible, tricky but possible. This the scanario I have in mind:
- I find a place on Earth
- I check with the MPC burst Map the corresponding burst ID that covers the area
- Reading the annotations file I find the burst ID, which is in a given āburst listā with items numbered from 1 to 9, and then I know the local number (1-9).
For data previous to IPF 3.5.x this is just impossible.
MZ
Could you please confirm the formula for calculating the relative orbit number of Sentinel-1B? I came across a different formula in this source
2021-1_TR_S1_burst_number.pdf (140.2 KB).
Thank you.
The annotation of relative orbit number in S1A products and the S1B products are as follows:
for S1A:
relative orbit = (absolute orbit - 73) % 175 + 1
For S1B
relative orbit = (absolute orbit - 27) % 175 + 1
For S1B this can be checked for instance in this product S1B_IW_SLC__1SDV_20210731T233709_20210731T233736_028044_03586A_4426.SAFE
For which the manifest contains the following values that are matching the formula
<safe:orbitReference> <safe:orbitNumber type="start">28044</safe:orbitNumber> <safe:orbitNumber type="stop">28045</safe:orbitNumber> <safe:relativeOrbitNumber type="start">18</safe:relativeOrbitNumber> <safe:relativeOrbitNumber type="stop">19</safe:relativeOrbitNumber> <safe:cycleNumber>167</safe:cycleNumber> <safe:phaseIdentifier>1</safe:phaseIdentifier> <safe:extension> <s1:orbitProperties> <s1:pass>ASCENDING</s1:pass> <s1:ascendingNodeTime>2021-07-31T21:58:36.551222</s1:ascendingNodeTime> </s1:orbitProperties> </safe:extension> </safe:orbitReference>
(28044 - 27) MOD 175 + 1 = 18
1 Like
(post deleted by author)