You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For users who intend to work from L1 range-doppler products to derive alternate L2 products, due to for example a different DEM choice, it would be helpful to have the GIM geolocation correction information (range delay correction) available as metadata in the L1 RD products.
The text was updated successfully, but these errors were encountered:
I agree that would be nice. However in practice we are limited by the latency of the TEC products. Indeed latency is one of the reasons that we are not correcting ionospheric delay in RSLC product or adding the correction to RSLC. Otherwise an extra latency of up to 24 hours or more would be imposed on RSLC. However, we are providing the TEC corrections in two different forms to the users:
The ionospheric TEC products will be provided to the users. They are expected to be small files like orbit files, containing total TEC (TEC from ground to GNSS orbit) and top-side TEC (TEC between NISAR orbit and GNSS orbit) as a function of time along NISAR orbit samples at 10 seconds interval. Users should be able to use these TEC data directly to compute corrections themselves if they want to start from L1.
In our L2 geocoded products such as GSLC, we are providing 2-dimensional look-up table corrections for ionosphere induced timing errors in both range and azimuth directions. If users don't want to deal with the TEC data, they could directly use the computed timing corrections in the L2 products.
For users who intend to work from L1 range-doppler products to derive alternate L2 products, due to for example a different DEM choice, it would be helpful to have the GIM geolocation correction information (range delay correction) available as metadata in the L1 RD products.
The text was updated successfully, but these errors were encountered: