Support for multiple GNSS/GPS sources

[rzinke]

MintPy currently only supports the UNR NGL GNSS solutions, but others are available such as (S)ESESES. UNR support is hardcoded into the mintpy gps.GPS object and associated functions, but I have experimented with adding support for the additional source. Would it be of interest to the broader MintPy community to officially add modular support for other GNSS souces? If so, I could add that.

Thanks for any comments!

[yunjunz]

Hi @rzinke, I think it's very much desired to have support for other GNSS solutions. You are more than welcome to issue a PR for it!

[falkamelung]

Hi @rzinke, Absolutely! We should aim to support as much GNSS data sets as possible, also different solutions, if available. I am personally interested in the USGS data as well as their high-rate solutions (if there are). The UNR data can have issues. An ability to readily compare with data from other sources would be very hellpful . It would be good to have a github isuue/wiki on GNSS data sources, also listing data sets for which support could be implemented but we did not have the tine to do this. It would also be good to support (partially) restricted data sets as it might encourage people to open their data up.

[rzinke]

Great! I'll get started on it and have something in a few days. I'll open an issue, too.
One question: What is GPS-GSI?

[yunjunz]

That's for the GNSS data from the Geospatial Information Authority of Japan (GSI). I don't think their data are publically open and freely available, so I only have a few functions to handle them locally.

[rzinke]

I also noticed a discrepancy between the station lat/lons for the UNR and JPL/SIO ESESES site locations.

For the UNR stations, I see the GNSS function get_stat_lat_lon reads the reference lat/lon and the easting/northing distances from the reference coordinates, computes the azimuth and distance of the easting/northing for the first date in the time-series, and adds the two to get the site_lat and site_lon.

For the ESESES data set, latitude and longitude values are provided in the file header e.g., (here)[http://garner.ucsd.edu/pub/measuresESESES_products/Timeseries/CurrentUntarred/Clean_TrendNeuTimeSeries_comb_20240325/candCleanTrend.neu.Z].

These values are different by up to 100 m or more:

Interestingly, the "nominal station latitude/longitude" of the UNR data (see (tenv3 readme)[http://geodesy.unr.edu/gps_timeseries/README_tenv3.txt]) match almost exactly with the lat/lon of the ESESES files.

Certainly this needs some consideration, especially because 100 m distance is larger than most InSAR pixels.

[yunjunz]

Thank you @rzinke for bringing this up. Using the "norminal station lat/lon" of the first date, instead of calculating it as done in the current code, makes more sense to me.

I can not recall why I was using the easting/northing distance/azimuth anymore (it's 5+ years ago and UNR was using the IGS08 at the time, which is now not available).

[rzinke]

Many thanks for the help on this, @yunjunz, and for the thoughts, @falkamelung. I have one comment and one question:

• Comment: We will need to update the MintPy tutorials
• Question: Will the updates be propagated to the conda-forge channel? We will need these for NISAR cal/val.

Thanks!

[yunjunz]

I will cut for a new release soon, after the recent hyp3 PRs got merged, then the new GNSS feature will be available on conda-forge.

As for the notebook tutorial, I believe only two of them are relevant: the smallbaselineApp_aria, and plot GPS.