Unable to generate footprint with unknown GEOS exception

[jlaura]

ISIS version(s) affected: 4.3.0

Description
When attempting to generate a footprint on a L2 product using footprintinit from=/scratch/jlaura/europa_mosaics/GLL_Obs/equi/33ESGLOCOL01_GalileoSSI_Equi.cub I am seeing the following error:

**USER ERROR** Cannot generate polygon for [33ESGLOCOL01_GalileoSSI_Equi.cub].
**ERROR** Unable to create image footprint (Fix360Poly) due to unknown exception.

It does not seem to matter what linc/sinc I select. Due to the geometry of many of the other images (and the small size), I have been using sinc=1 and linc=1.

How to reproduce
Data are internal at this point and are staged here:
footprintinit from=/scratch/jlaura/europa_mosaics/GLL_Obs/equi/33ESGLOCOL01_GalileoSSI_Equi.cub

Here are some other images with identical behavior:

• C9ESGLOBAL01_GalileoSSI_Equi.cub
• 33ESGLOCOL01_GalileoSSI_Equi.cub
• G2ESPHOTOM01_GalileoSSI_Equi.cub
• ../npola/10ESGLOBAL01_GalileoSSI_NPola.cub
• ../spola/25ESGLOBAL01_GalileoSSI_SPola.cub

Possible Solution
???

Additional context
I can see that the catch block that is throwing starts here on line 1333, but the fact that this is an unknown exception really is not helpful.

[lwellerastro]

Huh, I never knew you could run footprintinit on mosaics!

Footprintinit errors most likely occur (in my experience) for images crossing the 0/360 longitude boundary, and/or the poles. For lower resolution flyby data I might have to try footprintinit a couple of times to get it to run, but sometimes it never does.

In the case of Europa Galileo data, I used the following footprintinit command:
footprintinit from=${infile} inctype=vertices numvertices=100 maxincidence=89 maxemission=85

and if that didn't work, then I tried:
footprintinit from=${infile} inctype=vertices numvertices=80 maxincidence=89 maxemission=85 increaseprecision=true

I typically try to limit the number of vertices because they can get crazy otherwise and I'm dumping the footprint into a database which can get chunky and I don't need that level of detail.

I found with flyby data that if I left the incidence and emission to default I would get more failures than if I used a trim. Plus it's easier to view the footprints in qmos when the junk is trimmed off.

Something you might want to try for your failures.

And yes, a better error may be helpful.

[jlaura]

Doing a little bit more work on this using the suggestions from @lwellerastro. I am seeing similar issues on some of these data still:

**USER ERROR** Cannot generate polygon for [spola/G2ESPHOTOM01_GalileoSSI_SPola.cub].
**ERROR** Unable to create image footprint (Fix360Poly) due to unknown exception.
**I/O ERROR** Unable to open polygon [footprint] in file [spola/G2ESPHOTOM01_GalileoSSI_SPola.cub].
**I/O ERROR** Unable to read polygon [footprint].
**PROGRAMMER ERROR** Unable to find polygon [footprint].

Is the error perhaps happening where the data cross the 0-360 boundary? The error message above is for data in a polar projection. I am seeing the same error for equirectangular projections on some data. I'll play around with the incidence / emission clipping to see if that helps.

Whether that works or not, a better error message would be wonderful.

[rbeyer]

Definitely seeing this under ISIS 5.0.1 for a camera-geometry distant flyby image of Charon which has both the north pole and the prime meridian in the scene. Default inctype=lincsinc fails with

footprintinit fr=cubes/lor_0298204274_0x630_sci.cub increaseprecision=True linc=25 sinc=25 limbtest=spiceinit maxemission=88 maxincidence=88
**USER ERROR** Cannot generate polygon for [cubes/lor_0298204274_0x630_sci.cub].
**ERROR** Unable to create image footprint (Fix360Poly) due to unknown exception.

but succeeds with:

footprintinit fr=cubes/lor_0298204274_0x630_sci.cub increaseprecision=True inctype=vertices numvertices=100 limbtest=spiceinit maxemission=88 maxincidence=88
Group = Results
  SINC = 1
  LINC = 1
End_Group

Creation of the cube is as follows:

1. Download lor_0298204274_0x630_sci.fit from Small Bodies PDS node
2. lorri2isis fr=lor_0298204274_0x630_sci.fit to= lor_0298204274_0x630_sci.cub
3. editlab fr=lor_0298204274_0x630_sci.cub opt=modkey grp=Instrument key=TargetName value=Charon
4. spiceinit fr=lor_0298204274_0x630_sci.cub
5. footprintinit as above.

[rbeyer]

Hmm, but if I go back to my first run above, but omit increaseprecision=True I don't get that error (but now my 25 pixel increment is too small (Charon is only about 20 pixels across in this image). But if I manually dial that down to 5, then it completes.

So I just thought that increaseprecision was doing "automatically" what I did by running it without and manually decreasing the increments, but maybe it is also doing something else?

[github-actions]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

[jlaura]

I am again working on processing data and seeing this issue crop up. Instead of opening a new, active issue, I am going to reactivate this one.

@AustinSanders How do you want me to label this so that it percolates for a support sprint?

[AustinSanders]

@jlaura I normally use milestones to indicate that an issue should be included in the next support sprint. If it's not clear which milestone should be used next (7.1.0 or 7.0.1), then we can also just include it in the continuous support board. Those issues are always considered for next dedicated sprint.

[Kelvinrr]

@jlaura Is there any test images still available?

on astrovm4:

(base) -bash-4.2$ ls /scratch/jlaura/europa_mosaics/GLL_Obs/
ls: cannot access /scratch/jlaura/europa_mosaics/GLL_Obs/: No such file or directory

[lwellerastro]

@Kelvinrr, the final Europa products @jlaura would have pulled from would have come from here: /archive/projects/europa/GLL_FinProducts/, however, these are organized by observation whereas Jay's versions likely all resided in a single directory for ease of access.

The file in his original post was found this way:

ls /archive/projects/europa/GLL_FinProducts/*/33ESGLOCOL01_GalileoSSI_Equi.cub
/archive/projects/europa/GLL_FinProducts/33ESGLOCOL01/33ESGLOCOL01_GalileoSSI_Equi.cub

The others he listed can be found in a similar manner. I confirmed (via 5.0.2) that I get the same error he does when sourcing the file in the /archive directory.

[Kelvinrr]

@lwellerastro Thanks Lynn, I was able to replicate with that.

[Kelvinrr]

So adding an additional catch to the try/catch block to capture a std::exception very quickly gave me the real error:

**USER ERROR** Cannot generate polygon for [33ESGLOCOL01_GalileoSSI_Equi.cub].
**ERROR** Caught std::exception: IllegalArgumentException: Points of LinearRing do not form a closed linestring.

Putting the generated points into a geojson viewer quickly shows the footprint isn't closed (and from the coordinates it's definitely a 360 boundary cross problem as it's trying to be closed with -0.317487 instead of 359.683).

Re-projecting using map2map and the default equirectangular map file in the ISIS repo seems to make the footprint generate just fine (with linc/sinc=10)? I can continue looking into why the "fix 360" code is failing on the archive version as it seems fixable, but maybe it is also a data problem?

[lwellerastro]

Re-mapping in the way you did results in a new mosaic with 503 samples, versus the original of 494. Everything else numerically looks the same. What is going on there?

I looked at both mosaics in qview and the re-mapped version has NULL pixels in sample 1 now, which has negative longitudes (negative in both versions of the mosaic). That is not something I did - all of the products were run through automos.

I'm not sure why automos is adding negative dn's on the left side of the mosaic for images covering longitude 0-360 in a 360 domain. That sort of seems odd to me. This particular mosaic has only 2 input images and both have the same basic mapping information in the Mapping Group.

The other mosaics Jay mentions contain images that cross the 0/360 longitude boundary.

Aside: Oh, cool trick, try clicking on a pixel in that negative longitude zone and you will be transported to opposite side of the mosaic. I've actually seen this recently in a different project, but different data and I thought it had to do with an initialized mosaic having 360 londomain, but an image or two that were added had 180 and things getting goofy from that. Maybe not.

[Kelvinrr]

Alright, after stepping through the code, I think I found the issue. Basically, there is a part of the code that tries to handle the poles being in the image and splits the polygon up. The image manages to hit this case despite the poles not technically being on the body as that corner of the image is null. Using mappt on line=0.971409 sample=1.44282 seems to come back empty as the projection call back invalid, but for some reason mappt with lat=90 lon=0 gives a line sample? Because of this, the code that is supposed to help handle cases where the body's pole is in the image completely mangles the footprint's lat/lon coordinates.

Adding a check to make sure the line/sample that comes back from the projection object has a valid, non null, pixel with ImagePolygon::SetImage seems to have fixed the issue and now we have a multipoly split across the 360 boundary.