Bug #5233

automos - extra line when user enters range matching default calculated range

Added by Lynn Weller almost 2 years ago. Updated 11 months ago.

Target version:
Software Version:
Test Reviewer:


Test data are here: /work/users/lweller/Isis3Tests/Automos/ExtraLine/

Steps to reproduce:
1) Build mosaic letting automos calculate the lat/lon range of output mosaic

automos fromlist=cubs.lis mosaic=Mos_DefLatLon.cub

2) Build mosaic for same images entering the lat/lon range using the values calculated in output of step one
I just "more'd" Mos_DefLatLon.cub and copied and pasted the min/max lat/lon values onto the command line

automos fromlist=cubs.lis mosaic=Mos_UserLatLon.cub grange=user minlat=33.754519976271 maxlat=42.344869487402 minlon=-80.6546860985 maxlon=-78.212373873005

3) Compare output files - expected to be identical

cubediff from=Mos_DefLatLon.cub from2=Mos_UserLatLon.cub
Group = Error
Program = cubediff
Class = "USER ERROR"
Code = 2
Message = "The number of lines in the secondary input cubes must match the
primary input cube or be exactly one"
File = Process.cpp
Line = 111

4) Dump the labels and compare to see what all the differences might be

catlab from=Mos_DefLatLon.cub to=label_DefLatLon.txt
catlab from=Mos_UserLatLon.cub to=label_UserLatLon.txt
diff label_DefLatLon.txt label_UserLatLon.txt

Here is where the differences are (side by side) - I can't copy what is on my screen to redmine because redmine messes things up by trying to interpret the diff chevrons:
TileLines = 268 | TileLines = 463
Lines = 5092 | Lines = 5093
StartByte = 29558401 | StartByte = 29564193
Bytes = 5809 | Bytes = 5958

Note that the Mapping Groups are identical, yet somehow the number of lines vary. I don't know what controls TileLines or why that would be different - maybe that is the root of the problem.

This problem occurs under isis3production2017-10-24 on astrovm4 as well as isis3production2016-11-22 on astrovm3, which means it's in a variety of public releases. I don't know how far back this issue goes.

It would be useful if someone verified this problem with there own projected files (ready to mosaic) - maybe Jac or Bob? I would stay away from polar files since there is already an automos post with a similar problem associated with that sort of data (which I will relate this to. If other data are not easy to come by maybe the automos app test data could be used?

Related issues

Related to ISIS - Bug #4905: automos - polar stereographic mosaic UpperLeftCornerX/Y values possibly miscalculated when user enters lat/lon range Acknowledged


#1 Updated by Lynn Weller almost 2 years ago

  • Related to Bug #4905: automos - polar stereographic mosaic UpperLeftCornerX/Y values possibly miscalculated when user enters lat/lon range added

#2 Updated by Tammy Becker almost 2 years ago

  • Status changed from New to Acknowledged

Also available in: Atom PDF