search

insarlab / MintPy

Miami InSAR time-series software in Python
https://mintpy.readthedocs.io
Other
605 stars 259 forks source link

metadata inconsistency for UTM coordinates #1145

Closed Alex-Lewandowski closed 7 months ago

Alex-Lewandowski commented 8 months ago

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:

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: image

System information

welcome[bot] commented 8 months ago

👋 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 commented 8 months ago

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

forrestfwilliams commented 8 months ago

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 commented 7 months ago

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.