Bug #748

map2map failing for Oblique Cylindrical level 2 Enceladus files

Added by Trent Hare over 6 years ago. Updated over 1 year ago.

Target version:
Software Version:
Test Reviewer:


Out on /usgs/shareall/thare/ISIS3_Enc_bug_ObliqueCylindrical_bidr there are several Enceladus bidrs in PDS format (level2). Those have been converted to ISIS3 (using pds2isis) and all the map projection information appears to correctly be propagated. In Qview the lat/lon readouts also appear to be correct and we have (Randy and I) tested the features locations against a global basemap, EN_090624_DLR_basemap_i3.cub, also found in that directory.

Randy guess at problem:
Because it runs so fast and all that is returned are nulls where there use to be data, there seems to be a lat/lon range test that is failing and filling output with nothing. Please see Randy (or myself) during map projection debugging. Following one valid pixel through the equations should show us where it bailsâ?¦maybe.

Steps to reproduce:

The issue:
1.)Define a maptemplate (simple at first):
Group = Mapping
ProjectionName = SimpleCylindrical
CenterLongitude = 180.0
2.)Run map2map letting every default. The process run extremely fast and all that is returned is â??Lrsâ? and mostly Nulls.

1.)Define a maptemplate (more specific this time):

2.)Run map2map with clipping parameters around valid data. Only Nulls are return.

1.)Map2map global basemap using oblique cylindrical as template. Also appears to do correct thing (even though it doesn't have the same shape as template cube.
2.)Map2map back to global â?? still appears to be correct (missing data holes makes sense).
So this process seems to be doing the right thing.


#1 Updated by Janet Barrett over 6 years ago

Hi Trent,

You may have opened up a can of worms with this problem. Enceladus turns out to be a triaxial body. Triaxial bodies have never been properly supported by either ISIS2 or ISIS3. I have consulted with Randy on this and he suggested that I talk to Brent to see what the best solution is. I will keep you up to date.


#2 Updated by Janet Barrett over 6 years ago

This has been a hard problem to track down. The handling of triaxial bodies still needs to be fixed in ISIS3 so that it is done properly, but that is not the cause of your problem. I have traced backwards in the oblique cylindrical projection code and have found problems where longitude values were being treated as planetocentric even though they were actually planetographic. By fixing these situations, I now have map2map projecting your file, but there are still problems. The lat/lon reporting is still not quite right and part of your file is being trimmed off. I am still doing some testing. I am coming close to the 20 hour limit on this project and will need to ask Stuart if I can continue to work on it after today.

#3 Updated by Janet Barrett over 6 years ago

I have narrowed the problem down for doing map projections on Enceladus data in ISIS3. The oblique cylindrical labels contain PoleLatitude, PoleLongitude, and PoleRotation values. The ObliqueCylindrical class in ISIS3 was converting the PoleLongitude to planetocentric positive East, but it wasn't converting the PoleRotation to planetocentric positive East. This was causing major problems. I changed the code to convert the PoleRotation to planetocentric positive East and rand map2map on the e16_reproc1_seg2_3_bidr.cub that you were having trouble with. I created an oblique cylindrical output and a simple cylindrical output. The files are all located in /usgs/shareall/jbarrett/ISIS3_Enceladus_problem. I ran the new software change on a couple of other Enceladus files and it looks like it is working for them also. I will look for some Titan files to run it on and see if they are projecting correctly.

I have built /work/projects/isis/latest/m00748/isis for the astrovm* machines if you want to try it out on some other files before closing this post. Let
me know if you still see any problems.

#4 Updated by Janet Barrett over 6 years ago

Randy had the following reply (which means I need to go back to the drawing board and start over):

I was a bit skeptical about this fix, for two reasons
1) because we've had good coordinates from Titan BIDRs for years
(though we've mainly used ISIS2 to process them, so we need to
check ISIS3 for consistency), and
2) because the oblique pole rotation is not a longitude, so it should
not have to be converted from west to east for use if the file uses
west longitudes. Of course it's always possible that JPL misinterpreted
the formulae and did convert the rotation angle to "west" so that
we have to convert it back.

Surprisingly, your test images look good. The coordinates of craters
clearly check out against the ISS basemap. However, when I checked
the labels, the rotation angle is 359.4 so the opposite of this is
0.6 and there will be only about a 1.2 deg longitude shift of the
image between the correct and mis-rotated versions, regardless of
which is which.

I would like to check the results with other Enceladus files with
larger rotation angles, but I don't think there are any. I checked
the "E001" files (S01, 02, 03) I have, and their rotation angle is
only 0.9 deg. The 3 angles are based on the location of closest
approach so they will be the same for all the files from a given flyby.
I think the reason the rotation angles were small is because the
spacecraft was basically going east-west at closest approach.
Picking an image (necessarily from Titan) where the flyby was
more north-south would lead to a bigger rotation angle and a
much more sensitive test.

There are a complete (or at least very large) set of Titan BIDRs in
PDS format in /archive/projects/cassini/RADAR/JPL_Files. I grabbed
the T028S01 image from the 2008May29 folder. This image runs
very north-south and its rotation angle in the PDS label is 144.19.
I didn't try your new ISIS but I imported it into the version of ISIS on
my Mac. The rotation angle isn't changed when it's imported, it's
still 144.19. The lat-lon coordinates of a point near Ligeia Mare
are the same in this file in ISIS3 qview and in an old ISIS2 cube I
made in 2008 and displayed in ISIS2 qview today.

BTW this just reminded me that JPL makes additional files for each
BIDR and these include ones with the latitude of every pixel and
the longitude of every pixel. Therefore, we can check the coordinates
against what JPL thought they should be. In any case, it's clear that
ISIS2 and the old ISIS3 are giving the right answer for an image that
is truly very oblique on Titan.

Here's a different check. The three angles, with oblique pole longitude
expressed positive east, can be used to compute a rotation matrix
as defined in the SIS. This can be done by calling the NAIF routine
eul2m with the correct rotations around the correct axes. The
rows of this matrix should agree with the three oblique pole x/y/z
axis vectors in the label, and we can check for agreement to full
precision rather than looking at crater locations that we only measure
to about a degree. If I am reading the SIS correctly,the three rotations
to be input to eul2m are the oblique pole longitude, pi/2 minus
the oblique pole latitude, and the oblique pole rotation, and the
axes are 3, 2, 3.


#5 Updated by Trent Hare over 6 years ago

Janet needs to reopen the ticket based on Randy's comments

#6 Updated by Janet Barrett over 6 years ago

I am continuing to look into this problem. Randy gave me some JPL files that contain the lat/lon information for each pixel in the Enceladus files. I will use these files to help me track down the problem.

#7 Updated by Janet Barrett over 6 years ago

After much searching in the code and not finding a reason for the Enceladus problem, I suspected that the labels of the Enceladus files were not valid. In order to verify this, I needed to have a small amount of Randy's time so he could come to a conclusion that the problem is in the labels instead of the software.

It is very difficult to confer with Randy on technical problems because he has been tasked with doing mostly administrative work and has very little time to divert towards helping with technical questions. I feel that it is a total waste of Randy's time to have him doing administrative work rather than doing work in his area of strength which is helping with technical questions. He is a subject matter expert on many topics and it was very useful to be able to approach him with questions before his time was completely taken away to do admistrative duties. This is a severe detriment to the team.

Randy determined that the actual problem with the Enceladus labels lies in the LINE_PROJECTION_OFFSET keyword of the PDS labels. Randy knows the history of the creation of the Enceladus labels and sent the following email to the Cassini team to let them know about the problem:

Hi All:
Janet Barrett and I keep looking at the issue of Enceladus images
that don't reproject properly in ISIS, though we keep getting pulled
off to other priorities. I'm glad to say we now think we've identified
the source of the problem and a cure. I'll start with the cure for
the benefit of those who are short on time.

A short term fix to make it possible to work with the "problem" files
(in either ISIS 2 or 3) would be to hand-edit the PDS label before
ingesting into ISIS. If LINE_PROJECTION_OFFSET is very negative
and the image does not project properly, fix the value according to


The longer term fix would be to redeliver the files with the offset
values fixed in this way. I imagine there will need to be some discussion
of the priority and schedule for doing this.

Now, here's the full story of what is happening in the projection
To refresh everyone's memory, the problem was that some of the
Enceladus E16 HiSAR files produce an empty output file (all nulls, no
image pixels) when reprojected in ISIS 3. Attempting to reproject in
ISIS 2 just causes the program to crash. However, if one views the
original file in either version of ISIS, the lat-lon coordinates read out
at the cursor location look to be correct.

Other relevant information is that a couple of the E16 HiSAR files
reproject OK, so does the E16 full res SAR swath, the earlier E7
HiSARs, and of course all the Titan BIDRs. The projection and label
info ought to be the same for all these files so it was a mystery
why some worked and some didn't.

We tracked the difference between BIDRs that work normally in
ISIS and those that don't to the value of the PDS keyword
LINE_PROJECTION_OFFSET. This parameter has the effect of
controlling the range of the "oblique longitude" coordinate used
deep down inside the oblique projection. Oblique longitude basically
corresponds to angular progress along the flyby path, with zero at
the point of closest approach.

The "normal" situation in which there are no problems occurs when
the image starts before closest approach and continues through it.
The SAR strips for Titan and Enceladus fall into this category.
In this case LINE_PROJECTION_OFFSET > 0, which means the "origin"
(zero of oblique longitude and oblique latitude) comes after the first
line of the image. Since the equation relating oblique lon to line number
is linear, this means the oblique lon starts out negative and goes
through 0. Put another way, the "system" for oblique lon is -180 to 180.
The ISIS software currently checks the value of oblique lon and puts
it in this range if it's not.

Files that contain data only after closest approach are also not a
problem. In these, LINE_PROJECTION_OFFSET < 0 but the oblique
longitudes lie between 0 and 180 degrees. The E16 outbound
images fall into this category,or nearly so.

The "problem" files contain data only before closest approach
but instead of positive offset, the offset has a large negative value.
This results in the oblique longitude values calculated from the line
number being in the range 180 to 360. The calculation from line
and sample to oblique lat-lon to regular lat-lon goes OK because it
gives the same result for (say) 300 deg as for -60. The trouble
comes when we try to reproject. ISIS calculates an oblique lon in
-180 to 0 and the image only has values in the range 180 to 360,
so the appropriate pixel is not found. (In ISIS 2 there must be less
error checking, so the software tries to read a line that is outside the
file and just crashes.)


#8 Updated by Trent Hare over 6 years ago

Thanks for figuring it out.

#9 Updated by Ella Lee over 6 years ago


Do you know of any released PDS image that has this problem? The file I am testing has not been released through PDS yet.

Ella Mae

#10 Updated by Janet Barrett over 6 years ago

Hi Ella,

I tried to put a fix for this problem into the map2map program, but found that I could not make modifications to the PDS label once it was handed off to the low-level ISIS code. I was hoping I could modify the line projection offset value before any processing would be done, but this was not possible.

I did not realize that the problem images had not been released yet, so I did not check other files to see if they had the label problem also. Do you have a file/files that are released? If so, I could take a look at them to see if I find the problem.

If not, then I will see if I can find some released file on the PDS missions site.


#11 Updated by Anonymous over 5 years ago


#12 Updated by Anonymous about 5 years ago

  • Target version deleted (150)

#13 Updated by Tammy Becker over 3 years ago

  • Related to Bug #2244: Pixel (Line/Sample) Projection Offset Issue added

#14 Updated by Tammy Becker over 1 year ago

  • Status changed from Assigned to Acknowledged
  • Assignee deleted (Janet Barrett)

Unassigned Janet Barrett

#15 Updated by John Shinaman over 1 year ago

App test DOES NOT check the labels appropriately to check pixel offset.

#16 Updated by John Shinaman over 1 year ago

  • Test Reviewer set to John Shinaman

#17 Updated by Stuart Sides over 1 year ago

  • Related to deleted (Bug #2244: Pixel (Line/Sample) Projection Offset Issue)

Also available in: Atom PDF