Project

General

Profile

Bug #5148

automos - wierd behavior with incorrect user entered latitude and longitude range

Added by Tammy Becker 2 months ago. Updated 4 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Applications
Target version:
-
Impact:
Software Version:
Test Reviewer:

Description

Checks for incorrectly entered latitude ranges with automos seem to be missing. Automos continues to run and produces bad results.

For instance, I have a single image in polar stereographic with a latitude range of -90 to -30.

If I want to specify an output mosaic from this single input image with new latitude range of -90 to -80, the proper command would be as follows:

1) automos fromlist=sp.lis mosaic=test_LatRange-correct_automos.cub grange=user minlat=-90 maxlat=-80 minlon=-18.103736702471 maxlon=179.14115663253

The output is as expected. Full updated Mapping Group.

If by accident I swap the latitude range (min/max) as follows:
2) automos fromlist=sp.lis mosaic=test_LatRange-Incorrect_automos.cub grange=user maxlat=-90 minlat=-80 minlon=-18.103736702471 maxlon=179.14115663253

The output visually matches the input in terms of -90 to -30 (ignoring the -80 specification) and the Mapping group no longer includes BOTH
the latitude and longitude range keywords. It should have immediately failed as 'mapmos' does:
USER ERROR Parameter [MAXLAT] must be greater than parameter [MINLAT]

If I just happen to enter a positive latitude range for this south pole image as follows:
3) automos fromlist=sp.lis mosaic=test_NPLatRange-correct_automos.cub grange=user minlat=80 maxlat=90 minlon=-18.103736702471 maxlon=179.14115663253
a) not only does automos fail to report this input image is outside the range of what was entered,
b) it actually produces an output file that is 75,539 number of samples by 115,255 number of lines! It actually includes my image data!
c) it contains an updated mapping group with the latitude and longitude keywords that contain the values I entered.

If I keep positive north pole range for this input south pole image, but swap the min/max incorrectly as follows:
4) automos fromlist=sp.lis mosaic=test_NPLatRange-Incorrect_automos.cub grange=user minlat=90 maxlat=80 minlon=-18.103736702471 maxlon=179.14115663253

The output does not contain the latitude/longitude range keywords in the mapping group
The output looks like the #2 output

I have not yet run these scenarios with a non-curved projection, like equirectangular.

Location of images: /work/users/tbecker/IsisTesting/AutomosPoles/steps.csh
note: I will be deleting the #3 output soon, it created a 33G size file

automos_ouput_goodgoodbad.png View (302 KB) Lynn Weller, 2017-09-12 09:41 AM

History

#1 Updated by Tammy Becker 2 months ago

Triaged at a high level due to incorrect output.

#2 Updated by Lynn Weller 2 months ago

I have a test case for equi data in the following directory: /work/users/lweller/Isis3Tests/Automos/Extents/Equi/

1) I ran automos in default mode and let it calculate the lat/lon range of the output mosaic (input is 3 images). The output is as expected and the mapping labels are good.

automos fromlist=lev2.lis mosaic=Kaguya_Equi_DefaultRange_mos.cub

2) I ran automos again this time entering the proper lat/lon range (which I copied from the output of #1). Again, the output is as expected.

automos fromlist=lev2.lis mosaic=Kaguya_Equi_MatchDefaultRange_mos.cub grange=user minlat=59.512989543752 maxlat=60.566979879086 minlon=100.40157350435 maxlon=102.33363150903

3) I reran test 2 but I swapped the min and max latitude values expecting the program to fail. The program runs but the location of the input data is different than the previous runs (some, but not all images are Outside the bounds of the mosaic); the mapping group lacks the min/max latitude and longitude keywords; and the output mosaic is junk. The output mosaic appears to include all of the first image in the list and part of the second image. Really, the program should fail and let the user know the entered values are incorrect, no produce a bogus mosaic. I have not tried to swap longitudes to see what this does.

automos fromlist=lev2.lis mosaic=BadLatRange_Equi_mos.cub grange=user minlat=60.566979879086 maxlat=59.512989543752 minlon=100.40157350435 maxlon=102.33363150903

Attached below is a screenshot of the qviewed mosaics. From left to right is the output of #1, 2, then 3.

#3 Updated by Cole Neubauer 9 days ago

  • Assignee set to Cole Neubauer

#4 Updated by Cole Neubauer 9 days ago

  • Status changed from Acknowledged to Assigned

#5 Updated by Cole Neubauer 9 days ago

  • Status changed from Assigned to Resolved
  • Test Reviewer set to Tammy Becker

Build is in /work/projects/isis/latest/m05148/isis
Built for astrovm4

#6 Updated by Tammy Becker 9 days ago

Thank you! I will be able to test this tonight or first thing tomorrow morning.

#7 Updated by Tammy Becker 8 days ago

  • Status changed from Resolved to Feedback

automos now catches the obvious incorrectly entered min/max range order for both latitude and longitude. This avoids some crazy output.

There is one scenario that is probably outside the scope of this ticket. It involves the behavior of mapmos as well, and polar stereographic projection.

An input south pole image being asked to mosaic into a north pole latitude range is allowed in mapmos and automos, BUT, the Group =Outside Result is not reported with the input image listed as being outside the range (#3 in the original notes).

There should be a consistency between both mapmos and automos to report when any incoming image (or list of images in automos) fall outside the specified output mosaic range; north or south. I've tested the reverse with a north pole image being asked to mosaic into a south pole range, the Group=Outside result is reported, in both automos and mapmos.
Group = Outside
File = N1858923093_1_NP.cub
End_Group

The current "fix" for this scenario should be removed for now. This includes the new test, error and disallowing the output to be created. This will possibly break more reasonable projections where both poles can be included.

The following "fix" should be removed for now: this input south pole image that is being asked to map into a north pole range...a Group=Outside result should be the fix rather than disallowing the output. The error message is confusing because the max lat is an acceptable range.

automos fromlist=sp.lis mosaic=test_NPLatRange-correct_automos.cub grange=user minlat=80 maxlat=90 minlon=-18.103736702471 maxlon=179.14115663253
USER ERROR Paramater(s) [MAXLAT] outside the acceptable range.

#8 Updated by Lynn Weller 8 days ago

I am seeing similar issues as Tammy with my equi data that I provided below.

1) The check on min/max lat/lon values being entered properly works ok
automos fromlist=lev2.lis mosaic=BadLatRange_Equi_mos.cub grange=user minlat=60.566979879086 maxlat=59.512989543752 minlon=100.40157350435 maxlon=102.33363150903

Group = Error
Program = automos
Class = "USER ERROR"
Code = 2
Message = "Parameter [MAXLAT] must be greater than parameter [MINLAT]"
File = automos.cpp
Line = 74
End_Group
End_Object

2) BUT, I can not attempt to map my files into anything but their relevant lat/lon range without getting an error - this is bad
I'm entering a lat range that is just adjacent to my images to ensure it reports the files as OUTSIDE (which is what it correctly does under production):

automos fromlist=lev2.lis mosaic=Kaguya_Equi_OutOfBounds.cub minlat=45 maxlat=50 minlon=100.40157350435 maxlon=102.33363150903 grange=user
Group = Error
Program = automos
Class = "USER ERROR"
Code = 2
Message = "Paramater(s) [MINLAT] outside the acceptable range"
File = automos.cpp
Line = 196
End_Group

The production version of automos will initialize the mosaic and attempt to place the input cubes into it, and where it can't it will report
Group = Outside
File = MVA_2B2_01_01259N602E1017.lev2.cub
End_Group

This is correct and completely desired.

Whatever fix was applied to the command line checks seems to have exposed (or maybe broken) this other issue with automos.

#9 Updated by Cole Neubauer 4 days ago

  • Status changed from Feedback to In Progress

#10 Updated by Cole Neubauer 4 days ago

  • Status changed from In Progress to Resolved

The part of the build that was attempting to check range values has been removed. The newest build in /work/projects/isis/latest/m05148/isis only checks that the maxlon/maxlat parameters are larger than their min counterparts. It is my understanding the other issues that have come up in this ticket are going to be addressed in another ticket.

Also available in: Atom PDF