Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

metadata inconsistency for UTM coordinates #1145

Closed
Alex-Lewandowski opened this issue Feb 14, 2024 · 4 comments · Fixed by #1153 or #1161
Closed

metadata inconsistency for UTM coordinates #1145

Alex-Lewandowski opened this issue Feb 14, 2024 · 4 comments · Fixed by #1153 or #1161

Comments

@Alex-Lewandowski
Copy link
Contributor

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

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.
Copy link

welcome bot commented Feb 14, 2024

👋 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
Copy link
Contributor Author

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

@forrestfwilliams
Copy link
Collaborator

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
Copy link
Member

yunjunz commented Mar 12, 2024

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.

@yunjunz yunjunz reopened this Mar 13, 2024
@yunjunz yunjunz changed the title prep_hyp3 not updating coordinates in metadata after projecting to lat/lon metadata inconsistency for UTM coordinates Mar 13, 2024
@yunjunz yunjunz added this to the UTM coordinate support milestone May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment