-
Notifications
You must be signed in to change notification settings - Fork 265
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
Comments
👋 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! |
Oops, I forgot to mention that |
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. |
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 |
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:The discrepancies I noticed are:
EPSG
is not 4326REF_LAT
,REF_LON
,X_FIRST
, andY_FIRST
are northings and eastingsREF_X
andREF_Y
are correctWhile 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
The text was updated successfully, but these errors were encountered: