NISAR Data Latency

[jonathanbahlmann]

Dear Earthdata Forum,

currently I am working on understanding how NISAR data can be used in an operational sea ice monitoring context, e.g. for ship navigation. Data latency is thus a central topic.

If I understand the user guide correctly, availability of L1/L2 data is 1-3 days after acquisition - I am assuming that is because the medium precision orbit ephemeris files are only available the following day.

In an operational context, 1-3 days is already some time, so I'm trying to find out if there's any way one could get faster access to RSLC or GSLC products. For example, will the L0B RRSD data be available faster, and would it be feasible to process these on my own with a lower quality orbit file?

Happy to discuss any possibilities here.

Best,
Jonathan

[ASF - asjohnston]

Great question, thanks for posting!

Yes, you're interpreting the NISAR Data User Guide correctly. Reviewing performance from the last two months, we expect L0 data to be available to the public for download 1-12 hours after acquisition, and L1-3 data to be available 36-72 hours after acquisition. Those estimates assume nominal operations; there will be rare occasions where data will take longer to be available due to system outages or maintenance.

Yes, the primary driver for the L1-3 latency is waiting for medium precision orbit ephemeris files and other data required for processing to become available. NISAR is a research-focused mission, and there's a tradeoff between the data quality needs of the research/science community and the low-latency needs of the operations/urgent response community.

In the event of natural disasters or other major events, NISAR has the capability to produce L1-2 products using lower-precision orbit data and make them available to the public more quickly. For more details, see Section 2.5 of the NISAR Science Users' Handbook and the Urgent Response tab on the Earthdata NISAR page . ASF is in the process of documenting urgent response latency/process in more detail in the NISAR Data User Guide; I'll share here when that documentation is available.

Unfortunately, I suspect operational sea ice monitoring is unlikely to qualify for urgent response low-latency processing. I agree that processing the L0B RRSD data yourself could be a path forward. ISCE3 is the processing software used to produce NISAR data products. I don't have any personal experience attempting to create L1-3 data products, but I'll ask around and see if anyone else has experience to share.

[jonathanbahlmann]

Thank you for your swift reply.

The research mission focus, possible outages, and that routine sea ice monitoring is not an emergency scenario are of course all perfectly understandable.

This renders the 1-12 hours for L0 RRSD delivery all the more interesting, as that is a good basis to deliver data to ships in or near ice. If you could loop someone in like proposed, or know a person or place to reach out to, I'd greatly appreciate it!

[max.zhan]

Hey Jonathan, while looking into your inquiry, we do actually have workflows to manually process the L0B data to L1 in our NISAR environments faster than the 1-3 days, but while reviewing them we realized that without access to lot of NISAR S3 buckets, these workflows don't work out of the box and need tweaks to be able to use them on mirrors like ASF.

I'll try to briefly go over the process of turning an L0B RSSD file into an L1 RSLC, which is the hard part, starting with the expected processing time (your mileage may vary). This requires installing ISCE3 with the GPU CUDA libraries compiled. I believe this is available over conda forge, but alternatively you can look at https://github.com/isce-framework/isce3.git.

This conversion is through ISCE3's nisar.workflows.focus module (https://github.com/isce-framework/isce3/blob/static-layers-wip/python/packages/nisar/workflows/focus.py) and it requires a GPU:

- With double precision floating point cores on the GPU: ~1-2 hours per RSLC
- Without double precision cores: ~8 hours per RSLC

The cheapest GPU that has double precision cores is a V100. If you are planning to process this on the cloud like AWS, be aware that they don't offer these cheap GPUs anymore (p3.2xlarge), and all the newer GPUs that have this quality (H100's -> p5 instances) are being monopolized for AI training, so getting the instance itself will be a challenge.

The second challenge software-wise is that you need to obtain the DEM and the Watermask ancillary files. On the NISAR data system, we use these two scripts from ISCE3:
- nisar.workflows.stage_dem -> https://github.com/isce-framework/isce3/blob/develop/python/packages/nisar/workflows/stage_dem.py
- nisar.workflows.stage_watermask -> https://github.com/isce-framework/isce3/blob/develop/python/packages/nisar/workflows/stage_watermask.py
These scripts require access to the nisar-dem S3 bucket, which can't be granted publicly, so these scripts need to be modified to point to a mirror on ASF instead (see: https://nisar-docs.asf.alaska.edu/nisar-dem/). An AI could help with this modification, like Claude Code or Gemini.

The final challenge is to fill out the correct runconfig and obtain the remaining ancillary files. You can do this by starting from an .rc.yaml file from the same frame you want to process for, that was taken at a different time, and modify the ancillary files and the start/end_time fields to the new time window (usually in about 12 day increments since it is a cycle). The remaining ancillary files:
- external_calibration: This is a static file per release ID, it won't change by frame or time
- internal_calibration: This is a static file per release ID, it won't change by frame or time
- antenna_pattern: This is a static file per release ID, it won't change by frame or time
- corner_reflector_file: This is a static file per release ID, it won't change by frame or time

And here are the last 2 ancillary files, which you may change:
- orbit: example is NISAR_ANC_J_PR_MOE_20260121T132557_20260119T205942_20260121T025942.xml
- pointing: example is NISAR_ANC_L_PR_NRP_20260121T210333_20260120T125942_20260121T185942.xml
These files will need to cover the time period you are processing for. For the orbit file, the example is a MOE file and you'd use the forecasted version (FOE) if you need it available sooner. All these files should be available on the ASF.

Before I continue discussing this topic any further, I think it's first worth asking whether the approach I've described thus far makes sense for your use case and/or processing constraints.

[jonathanbahlmann]

Hi Max,

thanks a lot for this comprehensive answer. I've asked around internally, and we do think it makes a lot of sense for us to process NISAR data this way - depending on the observation scenario. We'll have a look at the incoming data from July forward to do the final evaluation.

Thanks also for the detailed comments on GPU processing. I agree, it is painful at the moment. Still, I believe it can be worth the cost for us.

Regarding DEM and watermask: Is all I need to do here to adopt the links mentioned in the DEM VRT subsetting section https://nisar-docs.asf.alaska.edu/nisar-dem/#vrt-subsetting? Is that available for the water mask in the same way?

I've found the orbit and pointing data as collections on earthdata. The aux files for external_calibration, internal_calibration, antenna_pattern and corner_reflector_files are in the "NISAR Ancillary and Auxiliary Data" collection on earthdata.

I did not find any RRSD data yet, as it has not been a part of the test data release. My question would be how the runconfig attributes can be inferred from the RRSD metadata, as well as which ones are important/dynamic and which ones can be left static. It might make more sense to discuss this when there's data available.

My first step would be to try to set this workflow up on my workstation without GPU. Is there a parameter I can tweak to decrease processing time in order to see coarse results fast?

Also, are there any constraints on producing GSLC products from the RSLC level? Which module would do that?

[max.zhan]

For the DEM, that's right. The watermask files are similarly available, here is the S3 version of the links:

aws s3 ls s3://sds-n-cumulus-prod-nisar-products/WATER_MASK/v0.5/ --profile daac
PRE EPSG3031/
PRE EPSG3413/
PRE EPSG4326/
2026-02-11 18:20:01 21072 EPSG3031.vrt
2026-02-11 18:20:01 20022 EPSG3413.vrt
2026-01-16 20:14:57 22861 EPSG4326.vrt

Once you have an RSLC, to convert it to GSLC, the conversion is mostly straightforward via ISCE3's nisar.workflows.gslc module (https://github.com/isce-framework/isce3/blob/develop/python/packages/nisar/workflows/gslc.py). The only new ancillary file required for it is the TEC file, for which there is 1 per day. You would grab the TEC file corresponding to the radar time of the GSLC. The rest of the ancillary files are the same (dem_file, orbit_file, corner_reflector_file).

For the remaining parameters of the runconfig, the parameters you definitely need to change are the start and end times for the RSLC and the geocode parameters for the GSLC (top_left, bottom_right, output_epsg). The rest are mostly either static or related to metadata that will be stored in the file (e.g. relating to the metadata). However, to be clear I am not aware of every edge case for how parameters in the runconfig should be changed and in what situation, I am still working to improve my understanding of that myself. That is why I prefer finding a similar product's runconfig (as in, in the same frame, preferably same radar mode, and same CRID) to use a reference, to isolate the changes that are needed to be made to purely temporal ones.

For speeding up processing for testing, you could manually shorten the runconfig's start_time and end_time to get some partial results first. For coarse results I'm not entirely sure what the best practice is myself, but you could look at the focus.yaml schema (https://github.com/isce-framework/isce3/blob/develop/share/nisar/schemas/focus.yaml) to potentially get some ideas. For example, the azcomp block size and resolution has a comment that indicates changing it will affect runtime. Perhaps you could start by making that parameter coarser compared to a sample runconfig.

[jonathanbahlmann]

Are the watermask files available via earthdata as well (like the DEM)? I can find it in earthdata but I can't find links parallel to the DEM links in the above mentioned documentation (e.g. https://nisar.asf.earthdatacloud.nasa.gov/NISAR/DEM/v1.2/EPSG4326/EPSG4326.vrt). I'm asking because S3 access is restricted to the us-west-2 region: https://nisar-docs.asf.alaska.edu/aws-s3-access/#s3-access-limitations.

Seems like the TEC file becomes the new "latest available file" for the processing, as it seems to me it's published around 9PM UTC of the day after. Do you have any thoughts on manipulating the file to refer to the current day? This would be the approach I'd take to be able to process GSLC right after RSLC, possibly on the same day of acquisition. I guess we'll see if that introduces larger pixel displacements.

For the runconfig it is not yet clear to me how I would identify frame, orbit or timing of the RRSD data to acquire a matching runconfig file. But I'll have more concrete questions with the data release. Looking forward to that!

Thanks for the pointers on processing time, will keep those in mind.

[max.zhan]

Sorry if it was unclear, the S3 and earthdata paths mimic one another, so the watermask link would be for example:

https://nisar.asf.earthdatacloud.nasa.gov/NISAR/WATER_MASK/v0.5/EPSG4326.vrt

For determining the RRSD, we would use a static file called the NISAR Track Frame Database, it should be on the NISAR website as a .gpkg file. This geopandas database lists every frame with the following 2 columns: "startCY" and "endCY", which represent the approximate seconds since the beginning of the cycle for the planned radar start time and end time for each frame. Hence from here the approach is in 4 steps:
1. Get the start and end dates of the RRSD from the filename.
2. Determine the start date of the cycle the RRSD is in (the cycle index is in the name, but for very old RRSD files the cycle number was +5 greater than it should've been).
3. Convert the RRSD start/end dates to seconds elapsed since the cycle began.
4. Filter the Track Frame Database for rows intersecting with that relative time window.

So from a given RRSD, we can take the start and ends times of that RRSD, get the nearest cycle start date (roughly increments of 12 days since the first cycle at about 2025-09-23T06:02:27.793323), and get the timedelta in seconds since this RRSD began and ended. We can then check which columns in the Track Frame Database intersects with this via a pandas dataframe filtering like df[(df['startCY'] <= elapsed_end) & (df['endCY'] >= elapsed_start)]. Be careful of the edge case where the start and end times cross the cycle start date.

This filtering yields a list of track frames that intersect with the RRSD, and from the duration of the RRSD you can estimate the degree of coverage any given frame has, or whether this is a 2 second RRSD that is part of a mixed mode RSLC processing.

Once you have determined these rows, you can simply add the startCY and endCY times to the cycle start date we deduced. This yields for that row:
- start_time
- end_time
And you can find in the columns for that row this information:
- track: The track number, also called relative_orbit in the naming convention and runconfig
- frame: The frame number
- passDirection: Ascending or Descending
This deduction is usually within about 1 second of the precise data. Please keep in mind that since this is an estimate, the geocoding may be shifted slightly as a result without any further adjustments, 1 second of deviation could translate to a ~7 km shift (estimated by a frame being usually about 240 km and 35 seconds in length).

For the TEC file question, unfortunately I cannot comment on what the impacts would be using an older file would have, I think someone else more qualified would need to answer that one.

[jonathanbahlmann]

re: watermask: understood.

Thank you for outlining the procedure to link image times and frame numbers so extensively. So in a runconfig, the start and end times are the start and end times of the matching _frame_ that I want to process for, not the start and end times found in the data/RRSD - even when the RRSD is only partially overlapping, e.g. some seconds are missing after startCY or before endCY?

I have questions about the 1 second uncertainty associated with this procedure, because potential kilometer-scale errors are of course a concern.
Where exactly does this uncertainty stem from? Is it the offset between the NISAR Track Frame Database and the actual frame timing for a certain orbit, or is it that I can only estimate the nearest cycle start date with so much accuracy? Or both? Neither?

You're also mentioning "precise data" and "further adjustments". What are these exactly, does it mean I could be more precise about whatever is introducing this offset?