Automatic output ortho/pansh EPSG settings

[ehusby]

FYI @clairecporter

Adds 'auto' and 'utm' options to the --epsg argument. 'utm': closest UTM zone, 'auto': closest UTM zone or polar stereo

Adding this was trickier than I expected, mostly due to the unforeseen need to determine each source image's target EPSG code in the initial check for incomplete processing tasks (because the epsg code is part of the output ortho/pansh image filename). In order to do this, I relocated a big chunk of code that analyzes target image geometry from pgc_pansharpen.py into lib/ortho_functions.py to avoid code duplication.

@bagl0025 and @bakkerbakker: If either of you find a good chance to test out this branch (with or without using the new capability of the --epsg argument), it would be great to have some additional testing. I believe I've tested most all of the different option combinations on images in different geographic locations, but it'd be great to have some additional testing to make sure nothing broke. Thanks!

[bakkerbakker]

This functionality sounds great! I'll do some testing with the mosaic workflow.

[ehusby]

Thanks to @rzhou0206 for testing this! I realized I spoke too soon in today's meeting -- were you thinking you might have a chance to test this out on the mosaic workflow @bakkerbakker? If not, I think we should be safe to merge and if there do happen to be any issues I'll be able to address them quickly.

[ehusby]

I think at this point, assuming enough folks here have been working on a branch containing these changes, it's safe to say the changes haven't broken anything for normal ortho production. I'm in favor of merging this soon, so I can start thinking about changes to the documentation to support https://github.com/PolarGeospatialCenter/imagery_utils/pull/39

[bagl0025]

Erik,

I haven't been using this much. Most of my ortho_functions use has been on my own development branch to get rid of bash calls to gdal commands. If you do merge, is it possible to pull the changes into my dev branch without overwriting what I've done to my dev branch?

Brian

On Thu, Jul 15, 2021 at 9:39 AM Erik Husby @.***> wrote:

I think at this point, assuming enough folks here have been working on a branch containing these changes, it's safe to say the changes haven't broken anything for normal ortho production. I'm in favor of merging this soon, so I can start thinking about changes to the documentation to support

39 https://github.com/PolarGeospatialCenter/imagery_utils/pull/39

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PolarGeospatialCenter/imagery_utils/pull/38#issuecomment-880749883, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKODQ6NUPLVOMLEWMAOQZRTTX3XKRANCNFSM46DSIUYQ .

[ehusby]

@bagl0025 That's another good reason to get this merged sooner rather than later.

You will want to commit the changes you've made in your branch before pulling from master. Upon pulling from master, if you have uncommitted changes to files that were updated in the master branch, PyCharm will give you an error. If you have instead made commits to files that were updated in the master branch, then then PyCharm will notify you of merge conflicts and it will send you into the process of resolving the conflicts.

Alternatively, if you are still working on changes in your branch and don't want to commit them, you can try "stashing" them (look for this under Git options in PyCharm), and then "unstash" them after pulling updates from the master branch. As long as the stashed changes don't collide with changes made to files in master, then you can essentially continue testing where you left off. If it doesn't let you apply the stash, then you'd want to reset to the last commit you made to your branch before pulling in the changes from master. Which could possibly get messy.

Committing all changes you've made to your branch is the safest route. Then if you run into any issues with the merge conflict, I'm happy to help out on that front.

[ehusby]

@bagl0025 Another option is to just ignore the changes to master after we merge this PR. Then at the time you make a PR to merge your branch into master, GitHub will notify you of any merge conflicts.

However, I wouldn't recommend resolving merge conflicts through the GitHub interface -- PyCharm is much better for that. Which you can do by pulling from the master branch while you have your branch checked out.

[bagl0025]

Thanks. I'll go the commit route. My changes aren't too complex so I think this will work out.

Brian

On Thu, Jul 15, 2021 at 10:08 AM Erik Husby @.***> wrote:

@bagl0025 https://github.com/bagl0025 That's another good reason to get this merged sooner rather than later.

You will want to commit the changes you've made in your branch before pulling from master. Upon pulling from master, if you have uncommitted changes to files that were updated in the master branch, PyCharm will give you an error. If you have instead made commits to files that were updated in the master branch, then then PyCharm will notify you of merge conflicts and it will send you into the process of resolving the conflicts.

Alternatively, if you are still working on changes in your branch and don't want to commit them, you can try "stashing" them (look for this under Git options in PyCharm), and then "unstash" them after pulling updates from the master branch. As long as the stashed changes don't collide with changes made to files in master, then you can essentially continue testing where you left off. If it doesn't let you apply the stash, then you'd want to reset to the last commit you made to your branch before pulling in the changes from master. Which could possibly get messy.

Committing all changes you've made to your branch is the safest route. Then if you run into any issues with the merge conflict, I'm happy to help out on that front.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PolarGeospatialCenter/imagery_utils/pull/38#issuecomment-880773147, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKODQ6K5MK5IXKUKN34MVDTTX32X3ANCNFSM46DSIUYQ .