Small bug in EquatorialCylindricalShape class
I believe there may be a very small bug in this class. My understanding is the the class requires a DEM with an equirectangular map projection at the equator. More specifically, a SimpleCylindrical projection or an Equirectangular projection restricted to CenterLatitude = 0 (these two projections are identical). Looking at the cubes in the $ISIS3DATA/dems they indeed satisfy this condition. However, there is no check in the EquatorialCylindricalShape class to ensure this condition is met. Fortunately but obscurely this condition is tested in the ShapeModelFactory. The factory creates the proper type of ShapeModel based on the projection and returns DemShape for PolarStereographic and EquatorialCylndricalShape for SimpleCylindrical or Equirectangluar w/CLAT=0.
However, if a programmer explicitly used EquatorialCylindricalShape in their code and didn't use the factory class there could be an error. The fix is to give protected access to the Projection private variable in the DemShape class through an accessor method and then test in the constructor of EquatorialCylindricalShape using the IsEquatorialCylindrical method. This would also be useful since there is a need to get to scale() and resolution() methods too.
#2 Updated by Jeff Anderson over 1 year ago
After more review of the code I am inclined to think the bug is not quite a small as I thought. The reason why is the code appears to assume a simple cylindrical image is required but accepts equirectangular with non-zero center latitude. The problem boils down to the computation of dalpha which assumes a center latitude of zero ... or at least I think it does. This algorithm is very complex with sparse documentation so I could be wrong. Anyways ... this is an issue for images with oblique views (LROC NAC with serious roll of spacecraft) or limb images of small bodies (vesta, ceres, asteriods, etc)