metadata inconsistency for UTM coordinates

[Alex-Lewandowski]

Description of the problem

MintPy no longer requires that users loading HyP3 data first project to lat/lon. In fact, it now fails to load HyP3 data already in lat/lon. Having the ability to load data in their original CRS is helpful, but not all necessary metadata are getting updated with newly projected coordinates.

Running mintpy.utils.readfile.read on a velocity.h5 returns the following metadata:

{'ALOOKS': '4',
 'ANTENNA_SIDE': '-1',
 'AZIMUTH_PIXEL_SIZE': '56.4',
 'BANDS': '1',
 'CENTER_LINE_UTC': '48030.742489',
 'DATA_TYPE': 'float32',
 'DATE12': '20230301_20231027',
 'EARTH_RADIUS': '6372473.4258',
 'END_DATE': '20231027',
 'EPSG': '32612',
 'FILE_LENGTH': '2813',
 'FILE_PATH': '/home/jovyan/opensarlab-notebooks/SAR_Training/English/Master/1/MintPy/velocity.h5',
 'FILE_TYPE': 'velocity',
 'HEADING': '-167.2010234',
 'HEIGHT': '699428.6236999994',
 'INTERLEAVE': 'BSQ',
 'LAT_REF1': '32.38891315809475',
 'LAT_REF2': '32.38891315809475',
 'LAT_REF3': '30.338043519676116',
 'LAT_REF4': '30.338043519676116',
 'LENGTH': '2813',
 'LON_REF1': '-108.6029033784557',
 'LON_REF2': '-111.63069288815178',
 'LON_REF3': '-108.6029033784557',
 'LON_REF4': '-111.63069288815178',
 'NO_DATA_VALUE': '0.0',
 'NoDataValue': '0.0',
 'OG_FILE_PATH': '/home/jovyan/opensarlab-notebooks/SAR_Training/English/Master/1/S1AA_20230301T132030_20230313T132030_VVP012_INT80_G_ueF_F4BD/S1AA_20230301T132030_20230313T132030_VVP012_INT80_G_ueF_F4BD_unw_phase_clip.tif',
 'ORBIT_DIRECTION': 'DESCENDING',
 'PLATFORM': 'Sen',
 'PROCESSOR': 'hyp3',
 'PROJECT_NAME': 'tuscon',
 'P_BASELINE_BOTTOM_HDR': '-111.6236',
 'P_BASELINE_TOP_HDR': '-111.6236',
 'RANGE_PIXEL_SIZE': '46.0',
 'REF_DATE': '20230301',
 'REF_LAT': '3425920.0',
 'REF_LON': '488800.0',
 'REF_X': '601',
 'REF_Y': '1972',
 'RLOOKS': '20',
 'STARTING_RANGE': '799177.9833',
 'START_DATE': '20230301',
 'UNIT': 'm/year',
 'UTM_ZONE': '12N',
 'WAVELENGTH': '0.055465764662349676',
 'WIDTH': '3622',
 'X_FIRST': '440680.0',
 'X_STEP': '80.0',
 'X_UNIT': 'meters',
 'Y_FIRST': '3583720.0',
 'Y_STEP': '-80.0',
 'Y_UNIT': 'meters',
 'mintpy.compute.cluster': 'local',
 'mintpy.compute.numWorker': '32',
...

The discrepancies I noticed are:

• The reference latitude and longitudes appear correct.
• EPSG is not 4326
• REF_LAT, REF_LON, X_FIRST, and Y_FIRST are northings and eastings
• REF_X and REF_Y are correct

While the data are correctly projected, the mix of CRSs in the metadata causes some util functions to break and plots to display odd values along their axes.

A number of mintpy.utils.utils.coordinate functions are impacted, either breaking or returning x/y indices that fall outside the raster (in some cases, negative values).

Here is an example plot:

System information

• Operating system: Linux
• Python environment: Conda
• MintPy version: 1.5.3
• InSAR processor/product: hyp3
• As far as I have seen, this situation holds for any HyP3 SBAS stack.

[welcome]

👋 Thanks for opening your first issue here! Please filled out the template with as much details as possible. We appreciate that you took the time to contribute!
Make sure you read our contributing guidelines.

[Alex-Lewandowski]

Oops, I forgot to mention that X_UNIT,Y_UNIT, X_STEP, and Y_STEP also look like they need to be updated.

[forrestfwilliams]

Hey @Alex-Lewandowski, Forrest from the HyP3 team here. For HyP3 products we recommend not reprojecting HyP3 products prior to ingesting them into MintPy. This will ensure that all geospatial metadata are correct for your MintPy stack.

As you've noted however, we could do more to fully support UTM-based data in MintPy. In the plot you showed above, the indices represent the northing and easting of the data, which are the analogous to latitude/longitude for UTM-projected datasets. While these values are correct, the plot is denoting the northing values using scientific notation which is confusing.

In addition, I'm aware the GPS-based comparison workflows do not currently work with UTM-projected data. This is something we can fix as well.

[yunjunz]

This issue is great for bookkeeping this metadata naming confusion. Thanks!

The ideal solution is to use a neutral name for both WGS84 (lat/lon) and UTM (northing/easting) for all the related metadata names. But this will introduce major backward incompatible changes, so I prefer to do it in version 2.0. UPDATE: added this note to the version 2 roadmap.

Before that, here is the convention I am thinking: all metadata named LAT and LON should have values in lat/lon degrees for WGS84, or in northing/easting meters for UTM. So far, only REF_LAT/LON1/2/3/4 is not following this temp convention (correct me if I missed anything please), thus, needs to be updated. And these metadata are currently only used in save_hdfeos5, which should be updated as well.