UTM support for view --show-gps + dual-coord input for lalo2yx/yx2lalo()

[forrestfwilliams]

Description of proposed changes

HyP3 (and I believe NISAR as well) both output their InSAR products in UTM coordinates. While MintPy was originally designed to use lat/lon coordinates, has limited support for UTM datasets as well. Users have noted (i.e., issue #1145) that it would be nice to better support UTM datasets.

This PR adds some additional support for UTM datasets, in plotting and GPS comparison contexts by:

1. Ensuring UTM coordinate plot axes do not use scientific notation (see issue metadata inconsistency for UTM coordinates #1145)
2. Ensuring coords.coordinate.latlon2yx works with UTM coordinates
3. Ensuring coords.coordinate.geo2rdr works with UTM coordinates
4. Adding compatibility for UTM coordinates to GPS plotting functionality

To accomplish this, checks for the use of UTM coordinates were added to latlon2yx and geo2rdr. Also, the inputs for latlon2yx was changed from a coordinate and a coordinate type (lat or lon) to a pair of lat/lon or northing/easting coordinates. All uses of latlon2yx were changed to use this new input format.

Reminders

• Fixes metadata inconsistency for UTM coordinates #1145
• Pass Pre-commit check (green)
• Pass Codacy code review (green)
• Pass Circle CI test (green)
• Make sure that your code follows our style. Use the other functions/files as a basis.
• If modifying functionality, describe changes to function behavior and arguments in a comment below the function declaration.
• If adding new functionality, add a detailed description to the documentation and/or an example.

[forrestfwilliams]

Also related to discussion #1010

[forrestfwilliams]

Hey @yunjunz, I would appreciate your thoughts on this whenever you have time.

[yunjunz]

Thank you @forrestfwilliams for the PR! After some minor changes mentioned below, testing the GPS plotting based on the Ridgecrest example dataset via view.py worked for me.

As for the input arg changes for lalo2yx(), either the "single coordinate type" or the "pair style" is fine with me. Actually, the pair style looks cleaner. Could you do a similar change to yx2lalo() as well, for consistency?

[forrestfwilliams]

Thanks for the review @yunjunz! I've made the suggested changes, modified yx2lalo to match the structure of lalo2yx, and updated its uses. This is ready for you to look at again!

[forrestfwilliams]

Not sure why the pre-commit check is failing.

[yunjunz]

Not sure why the pre-commit check is failing.

Have you set up the pre-commit for your MintPy local repo, following the instructions here? All the checks and/or modifications will be done automatically when you do the git commit.

[yunjunz]

Looks all good to me now. Thank you @forrestfwilliams!

Although lalo2yx() and yx2lalo() have breaking changes, they are usually not heavily used by most developers I believe, as geo2radar() and radar2geo() are more generic and convenient, I think there will be only very limited impact on developers and advanced users.

[forrestfwilliams]

Awesome, thanks @yunjunz! Do you think we could create a new release of MintPy soon with these changes? I ended up pursuing this work to support some tutorials ASF's OpenSARLab team runs and it would be great to get them a new release with these changes.

[yunjunz]

Sure thing, let's cut for a new release for it. There are a few recently open PRs from the JPL folks, it will be nice to merge those before the new release, likely this week.

[yunjunz]

Hi @forrestfwilliams, I think the code is ready for a new release. As for the proposed changes in #1162, doing them either before or after the release is fine with me, let me know please.

[forrestfwilliams]

Hey @yunjunz sorry for the slow response. I'll open a PR for the changes discussed in #1162 next week, then we can release!