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

fixed error where footprint fails to generate on some map projected images. fixes #4390 #4908

Merged
merged 2 commits into from
Apr 15, 2022

Conversation

Kelvinrr
Copy link
Collaborator

@Kelvinrr Kelvinrr commented Apr 15, 2022

Description

Fixes bug where footprints fail to generate when these specific conditions are met:

  1. Input image is map projected
  2. target crosses the 0/360 boundary
  3. some line/sample in the image projects to the polar lat lons: (90,0) and/or (-90/0)
  4. that line sample that projects to (90,0)/(-90, 0) does not project onto the body/is a null pixel.

Which results in the image footprint becoming mangled.

Related Issue

#4390

Motivation and Context

Some map projected images were not generating valid footprints.

How Has This Been Tested?

Original image in the issue successfully generated it's footprint when it previous excepted with incomplete linear ring coordinates.

Screenshots (if appropriate):

using image: /archive/projects/europa/GLL_FinProducts/*/33ESGLOCOL01_GalileoSSI_Equi.cub

Footprint trying to cross the pole, had to use a web geojson app since I had incomplete coords I was just printing out:

Screen Shot 2022-04-11 at 2 48 44 PM

After fix, viewed in qmos:

Screen Shot 2022-04-14 at 10 19 35 PM

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Documentation change (update to the documentation; no code change)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have read and agree to abide by the Code of Conduct
  • I have read the CONTRIBUTING document.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • I have added myself to the .zenodo.json document.
  • I have added any user impacting changes to the CHANGELOG.md document.

Licensing

This project is mostly composed of free and unencumbered software released into the public domain, and we are unlikely to accept contributions that are not also released into the public domain. Somewhere near the top of each file should have these words:

This work is free and unencumbered software released into the public domain. In jurisdictions that recognize copyright laws, the author or authors of this software dedicate any and all copyright interest in the software to the public domain.

  • I dedicate any and all copyright interest in this software to the public domain. I make this dedication for the benefit of the public at large and to the detriment of my heirs and successors. I intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law.

Comment on lines +1333 to +1337
catch(std::exception &e) {
std::string msg = "Caught std::exception: ";
msg += e.what();
throw IException(IException::Unknown, msg, _FILEINFO_);
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

std::exception wasn't being caught causing the real error of an incomplete linestring to be swllowed by catch(...)

@@ -852,7 +850,8 @@ namespace Isis {

if (nPoleSample >= 0.5 && nPoleLine >= 0.5 &&
nPoleSample <= p_cube->sampleCount() + 0.5 &&
nPoleLine <= p_cube->lineCount() + 0.5) {
nPoleLine <= p_cube->lineCount() + 0.5 &&
SetImage(nPoleSample, nPoleLine)) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SetImage checks to see if the pixel can get a valid projection when going image->ground.

idk why ground->image successfully returns pixel coords but image->ground acknowledges that there is no intersection?

Copy link
Collaborator

@jlaura jlaura left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to build a dev version and test on the whole archive as well once this is merged.

@Kelvinrr
Copy link
Collaborator Author

gonna wait until test finishes

@acpaquette
Copy link
Collaborator

This should be good, only tests failing are the ones that have been fixed

@Kelvinrr Kelvinrr merged commit 5ddf012 into DOI-USGS:dev Apr 15, 2022
@jessemapel jessemapel mentioned this pull request Apr 17, 2022
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants