NISAR Data Latency

[jonathanbahlmann]

Alright, now I'm getting that the uncertainty you mentioned refers to the "frame/runconfig to RRSD dataset" matching - not to the pixel geolocation accuracy of the L1 or L2 products processed from the RRSD data. The geolocation accuracy of the processed products depends on the precision of the ancillary data like you described. The consequence of the matching problem, slight errors in the estimation of the bounding box of an RRSD dataset, is very much acceptable for my use case.

Parallel to the start and end timing I was wondering about the role of the "track_frame_polygon" in the runconfig, but I can see now that in the focus module of ISCE3 it is only used to calculate the frame coverage.

What I can't find much information on in the documentation is the "mixed mode". What is the purpose of this, how do the products combined here differ? The file naming convention for L1 mentions "S – 1 char for source of data for the product" for either "A" or "M" right before the radar start time. This is reflected in the runconfig by the variable "data_source". None of the example data over sea ice are in mixed mode, so I'm guessing it won't be very relevant for me here and there is a flag to filter out the "affected" runconfig files.

[max.zhan]

Your understanding is correct, the time estimation is just for the purposes of setting the runconfig. I did do some poking around and found that you can check STUF files (.xml) to get a slightly more accurate estimation of each cycle's start time to make the time range guessing a bit more accurate. I don't know if the DAAC archives these, but these are on the NISAR SDS operations buckets (same as the pointing/orbit files) so I'm guessing they do.

For the track_frame_polygon, this is just the "geometry" column in the track frame database, which is stored as a shapely polygon if you load it with geopandas. The format for the runconfig is a GeoJSON formatted string describing the bounding box you are expecting to cover.

mixed_mode refers to when your inputs include multiple RRSD files taken consecutively where the radar mode of the RRSD changes while still mid-frame. This will usually result in 3 RRSD files intersecting the frame per cycle:
1. An RRSD in the old mode
2. A 2-second RRSD in the new mode
3. A longer RRSD that is still the new mode.
The 2-second RRSD not being part of the 3rd RRSD is due to a quirk of flight rules that requires a 2-second pre-observation between mode changes, and thus the SDS processes it as a separate product. This type of RSLC is what is known as a mixed mode RSLC, and about ~2160 frames total are processed in this way, which is about ~13.5% of all frames with data in them.

I believe you can expect this to be purely a quirk of your frames. If there have been no mixed mode RSLCs ever created for the frames in your region of interest, you can safely ignore this feature.

[jonathanbahlmann]

Alright, now I'm getting that the uncertainty you mentioned refers to the "frame/runconfig to RRSD dataset" matching - not to the pixel geolocation accuracy of the L1 or L2 products processed from the RRSD data. The geolocation accuracy of the processed products depends on the precision of the ancillary data like you described. The consequence of the matching problem, slight errors in the estimation of the bounding box of an RRSD dataset, is very much acceptable for my use case.

Parallel to the start and end timing I was wondering about the role of the "track_frame_polygon" in the runconfig, but I can see now that in the focus module of ISCE3 it is only used to calculate the frame coverage.

What I can't find much information on in the documentation is the "mixed mode". What is the purpose of this, how do the products combined here differ? The file naming convention for L1 mentions "S – 1 char for source of data for the product" for either "A" or "M" right before the radar start time. This is reflected in the runconfig by the variable "data_source". None of the example data over sea ice are in mixed mode, so I'm guessing it won't be very relevant for me here and there is a flag to filter out the "affected" runconfig files.

[jonathanbahlmann]

Please disregard my above post, it is exactly the same as before. I was struggling with the pagination..

Thank you very much Max for all your explanations. I am looking forward to trying all that out soon.