doi-usgs/usgscsm

This repository stores USGS Community Sensor Model (CSM) camera models

USGSCSM

This library provides Community Sensor Model (CSM)-compliant sensor models created by the USGS Astrogeology Science Center.

USGSCSM contains three different sensor models. The first is a generic framing camera model written from scratch. The second is a generic line scan camera model based on code from BAE Systems Information and Electronic Systems Integration, Inc. The third is a generic synthetic-aperture radar (SAR) sensor model.

Using USGSCSM

This library is a CSM plugin library that is intended to be dynamically loaded at run-time alongside the CSM API library.

Once the library is loaded, it can be accessed through the CSM plugin interface. For an example of how to do through the CSM C++ interface see the SensorModelFactory class in SensorUtils. For an example of how to do this through the CSM Python bindings see this notebook.

From the CSM plugin interface, a generic framing camera model (USGS_ASTRO_FRAME_SENSOR_MODEL), line scan camera model (USGS_ASTRO_LINE_SCANNER_SENSOR_MODEL), or a SAR model (USGS_ASTRO_SAR_SENSOR_MODEL) can be instantiated from a suitable Image Support Data (ISD) file.

Camera model format and model state

Under the CSM standard, each plugin library can define its own ISD camera model format. This library uses an auxiliary JSON formatted file that must be next to the image file passed to the CSM::ISD class. ISD files and strings can be generated by using ALE with metakernels and accompanying SPICE kernels, or from ISIS cubes that have attached SPICE data.

The camera model read from an ISD file is converted at load time to an internal representation which makes camera operations more efficient. This optimized model state can be saved to disk as a JSON-formatted file, be used interchangeably with the original ISD model, and also shared among various photogrammetric packages.

The camera model state can be modified by an application of a rotation and translation, which is necessary in order to refine a camera's position and orientation in photogrammetry, while these operations are not easy to express in the original ISD format.

This library provides functionality for saving the model state file, as discussed in the next section.

Camera model processsing

USGSCSM ships with a program named usgscsm_cam_test, which is able to load a CSM camera model, whether in the original ISD format or its model state representation, export the model state, and perform basic camera operations, as described in its documentation.

Enabling logging

Logging of the internal operations in the sensor models can be enabled by setting the USGSCSM_LOG_FILE environment variable to the file the log should be written to. To have the logging information printed to the standard output or standard error, set this to stdout or stderr.

You can adjust how much information is logged by setting the USGSCSM_LOG_LEVEL environment variable. The log level is not case sensitive. The log levels are:

Level	Description
trace	Intermediate calculation values
debug	All function calls and returns
info	Only core photogrammetry calls and returns - Default log level
warn	CSM warnings
err	CSM exceptions
critical	Critical errors
off	No log messages

All log messages of level USGSCSM_LOG_LEVEL and below will be logged. For example, setting the log level to info will log all messages of types info, warn, err, critical, and off. Note that these logs can become several GB in size when the log level is set to debug or trace.

---

Build requirements

• cmake 3.15 or newer
• GNU-compatible Make
• a C++11 compliant compiler

This repository has all of its external C++ dependencies included in it. The excellent header-only JSON library JSON for Modern C++ is included directly in the source code. The other three dependencies, The Abstraction Library for Ephemerides, the CSM API library, and googletest are included as git submodules. When you clone this library make sure you add the --recursive flag to your git clone command. Alternatively, you can run git submodule update --init --recursive after cloning.

You can also install the build requirements using Conda with the provided environment.yml file. The following commands will create a new environment to build against. Note that googletest cannot be installed via anaconda and must be available within the source code. You can remove the googletest dependency by disabling the tests.

conda env create -n usgscsm -f environment.yml

Building USGSCSM

USGSCSM uses a standard cmake build system. To compile the library and tests use the following commands:

1. mkdir build && cd build
2. cmake -DUSGSCSM_EXTERNAL_DEPS=OFF -DUSGSCSM_BUILD_DOCS=OFF .. && cmake --build .

If you are using external dependencies via Conda or system level installations add the -DUSGSCSM_EXTERNAL_DEPS=ON flag to the cmake command.

You can also disable the tests and the googletest dependency by adding the -DUSGSCSM_BUILD_TESTS=OFF flag to the cmake command.

Testing USGSCSM

All of the tests for USGSCSM are written in the googletest framework and are run via ctest. To run all of the tests simply run ctest in the build.

All of the tests are purposefully written to use generic data that values have been hand validated. This data can be found under tests/data.

Code style

This software package uses a modified form of the Google C++ Style Guide.

Here are some exceptions:

1. Non-const pass-by-reference is allowed.
2. No copyright notice is necessary
3. Static/global string constants are allowed to be std::strings, rather than C-style strings

To attempt to automatically format any new code to this style, run: clang-format -style=Google -i file.cpp For more information see: ClangFormat

To check for compliance, run: cpplint file.cpp and ignore errors in the list of exclusions above. For more information, see: cpplint.

usgscsm's Issues

JenkinsIntegration Tests

Right now, libcsm (CSM), cycsm, and usgscam are all being independently CI-ed. We need to do integration tests where a change to any package launched both the travis CI tests and an in-house Jenkins CI run.

• A PR/Merge on one of the above repos also launches a Jenkins integration test
• Jenkins integration test has a badge in the repos

Finished ORex PolyCam Implementation

• Determine if the MapCam can utilize the generic framer
• Implement if necessary
• Generate tests

ISD schema should have documentation about units expected (e.g. radii)

The Wiki 'Getting Setup on the standard ISIS3 dev system.' is out of date

Except with the setup of the conda environment. That can probably remain.

Standardize ISD Keywords / State

The state keywords differ between the models that we have implemented. These should be standardized as follows:

• Create a wiki page with a table for the framing and line scanner keywords with each keyword on a separate line.
• Generate an RFC issue with a set of isd / state keywords
• Once we have consensus, refactor the code for standardize keywords.

A Wiki on creating tests and submitting them with PRs needs to be created.

Targeted Unit Testing for SET Functionality (EPIC)

This is an EPIC that needs to be decomposed into sub-issues. The SET for replicating phocube capability needs unit tests that use synthetic (non-image) data.

Create a simple fabricated “Pinhole” Framer ISD for test purposes

This includes simple rotation angles, location, etc

triaxial and irregular body support

Discuss triaxial issues and irregular body issues - who to handle within CSM API. For example, since the CSM implementation is up to user will the SET work if a irregular body might be used for I2G and G2I.

for more see: https://github.com/USGS-Astrogeology/CSM-CameraModel/wiki/CSM-and-triaxial

Can we have a single plugin for the library?

We have separate framing camera and line scan camera plugins right now. Can we combine those into a single plugin?

CTX Sensor groundToImage

The CTX tests were disabled during the last sprint. It looks like the groundToImage call is not working with CTX data. To replicate add the following to the test_genericls.py file:

class TestCTX:

    @pytest.mark.parametrize('image, ground',[
                              ((2500, 9216, 0), (-73589.5516508502, 562548.342040933, 2372508.44060771)),
                              ((100,100,0), (712929.1383706382, 3158202.49568922, 1019437.3888700278))])
    def test_image_to_ground(self, ctx_model, image, ground):
        gx, gy, gz = ground
        x, y, z = ctx_model.imageToGround(*image)

        #TODO: Get this test up and running.
        #print(x, y, z)
        #assert False
        assert x == pytest.approx(gx, rel=1)
        assert y == pytest.approx(gy, rel=1)
        assert z == pytest.approx(gz, rel=1)


    @pytest.mark.parametrize('image, ground',[
                              ((2500, 9216, 0), (-73589.5516508502, 562548.342040933, 2372508.44060771)),
                              ((100,100,0), (712929.1383706382, 3158202.49568922, 1019437.3888700278))])
    def test_ground_to_image(self, ctx_model, image, ground):
        y, x = ctx_model.groundToImage(*ground)
        ix, iy, _ = image
        assert x == pytest.approx(ix)
        assert y == pytest.approx(iy)

imageToGround has NOT been validated yet using an existing sensor model either. groundToImage fails with an error being raised for either the ground point not being in the image or the convergence failing.

Private static members

In MdisPlugin.h

I don't think this is necessary, since they are already forward declared in Plugin.h

namespace csm {
class Isd;
class Model;
class Warning;
}

Since the following are all private in MdisPlugin.h would suggest not declaring them in the header at all....

static const MdisPlugin m_registeredPlugin;
static const std::string m_pluginName;
static const std::string m_manufacturerName;
static const std::string m_releaseDate;
static const csm::Version m_csmVersion;
static const int m_numModels;

Instead, just declare them in the cpp file.

Appveyor

Get the windows build working on appveyor.

CI testing should be able to support including objects/namespaces in the SensorUtils lib

At some point in the future. It doesn't have to happen immediately.

Integrate CTest with Travis

Targeted Unit Testing for ISD Functionality (EPIC)

This is an epic that needs to be decomposed into sub-issues. The ISD generation should be generated using TDD. The unit testing should be using synthetic data.

Infrastructure

• Jenkins connected to git repo(s)
• CMake Templating / CMake files SET
• CTest as a testing framework
• [ ]

Add support for radial distortion models in the generic frame camera model

We need to do this.

insert giant list of cameras that have radial distortion here

understand velocity blobs in ISIS3

From socetlinescankeywords many references to an issue in in ISIS3 for velocity blobs. Is this something we can help within CSM?

see:
https://github.com/USGS-Astrogeology/ISIS3/blob/d02a0e04c2b9725a71633140108615db8ccc777a/isis/src/socet/apps/socetlinescankeywords/socetlinescankeywords.cpp#L422

Testing i2g and g2i script running down center of image -- output CSV

This could be a Python script or Jupiter notebook simply running down the center of the image testing about every ~100 rows. The output CSV should emulate a Socet SET program we had to do the same called "SsIsisValidationG2I_imgLength". I think it could also run down both sides (~10% in from the side).

original code: /work/projects/socetset/DPW/SSv56/devkit/SENSOR_MODELS/SsIsisValidationG2I_imgLength/SsIsisValidationG2I_imgLength.cpp

more (from original .cpp header):
// This program gathers the Socet Set information needed to validate ISIS->SOCET SET
// translation code and/or newly developed Sensor Models by comparing the ground-to-image results
// in ISIS and SOCET SET. The input images used for these tests must have been spiceinit'ed
// to the ellipsoid in ISIS. In SOCET SET, we must gather ground-to-image calculations at
// Z/ELEV =0.0 because ISIS assumes Z/ELEV =0.0 when spiceinit'd to the ellipsoid.
//
// This program will also compare the SOCET SET Sensor's model forward and backward
// calculations (ImgToGrnd then GrndToImg) and report the difference in the starting
// and ending line/sample calculations.
//
// This program will gather GrndToImg results at he CENTER of the image, and 10% in from
// the image corners for UL, UR, LL, LR results. To get the input ground coordinate, it starts with
// ImgToGrnd calculations at the CENTER, UL, UR, LL, LR image coordinates. The resulting ground
// coordinate is then used as input to GrndToImg. The input ground coordinate to GrndToImg, and the
// output image coordinate from GrndToImg are written to an output csv file, which will be an input file
// to ISIS script SsIsisValidationGrd2Img.pl. This ISIS script will gather the ISIS results, and
// difference the SOCET SET and ISIS line/sample results.
//
// Furthermore, this program will convert and report the various coordinate systems and formats used
// in SOCET SET and ISIS. The header line in the output CSV will contain an "ss" prefix on the SOCET
// SET values, and an "isis" prefix for ISIS values. Each column in the CSV file is as follows:
//
// Update for CSM
//
// ISD_Name:
// The ISD used for processing the image
//
// imgRegion (optional):
// CENTER, UL, LL, UR, LR regions tested
//
// csmImgCentLine_I2G, csmImgCentSamp_I2G:
// SOCET SET image-centered coordinate input to image2ground
//
// csmLatOG, csmLon180, csmElev:
// Ground coordinate lat/lon/Elev result from image2ground
//
// ssImgCentLine_G2I, ssImgCentSamp_G2I:
// image-centered coordinate result from ground2image
//
// csmSensorDeltaLine, csmSensorDeltaSamp:
// Difference in line/sample coordinates btw image2ground and ground2image
//
// csm2isisLine_G2I, csm2isisSamp_G2I:
// ground2image image coord converted to ISIS line/sample coord
//
// isisLatOC,isislon360:
// CSM lat/lon coordinate in ISIS ocentric-lat/E360-lon system
///////////////////////////////////////////////////////////////////////////////

Some of the helper functions just to show the pixel and lat/lon conversion to ISIS coords. Last function just for ographic to ocentric lats.

image_point_struct
isis2ssLS(image_point_struct isisPt, int nlines, int nsamples)
// Convert ISIS line/sample coordinates to SOCET SET image-centered coordinates
{
   image_point_struct ssPt;
   ssPt.line = isisPt.line - 0.5 * nlines -1.0;
   ssPt.sample = isisPt.sample -0.5 * nsamples - 1.0;
    return(ssPt);
} // End isis2ssLS

image_point_struct
ss2isisLS(image_point_struct ssPT, int nlines, int nsamples)
// Convert SOCET SET image-centered coordinates to ISIS line/sample coordinates
{
   image_point_struct isisPt;
   isisPt.line = ssPT.line + 0.5 * nlines + 1.0;
   isisPt.sample = ssPT.sample + 0.5 * nsamples + 1.0;
    return(isisPt);
} // End ss2isisLS

void
ss2isisGRD(ground_point_struct ss_gp, double eccSqr, double *ocLat, double *lon360, double *Elev)
// Convert SOCET SET lat/lon coordinates to ISIS lat/lon coordinates
{
  double r2d=57.295779513082320876798154814105;
  if (eccSqr == 0.0)
    *ocLat = ss_gp.y * r2d;
  else {
    *ocLat = atan(tan(ss_gp.y) * (1-eccSqr)) * r2d;
  }
  if (ss_gp.x > 0.0)
    *lon360 = ss_gp.x * r2d;
  else {
    *lon360 = ss_gp.x  * r2d + 360.0;
  }
  *Elev = ss_gp.z;
  return;
} // End ss2isisGRD

Correlation Model

In the example CSM implementations I have seen, they are use the csm::NoCorrelationModel. This is an open ticket as a reminder to start to look at when one of the CSM provided correlation models should be used. For now, the MDIS (WAC & NAC) camera model will mirror what I have seen in the examples.

Finished ORex MapCam Implementation

• Determine if the MapCam can utilize the generic framer
• Implement if necessary
• Generate tests

Generic line scan camera does not correctly calculate sub-pixel look vectors

The losToEcf method in the generic line scan camera model computes a look vector from an image coordinate. It correctly accounts for fractional samples, but it doesn't account for fractional lines. Regardless of what the entered line value is, it is always assumed to be the center of the nearest line.

This method is used in both image to ground and ground to image.

Set up ctest

We've tried gtest in the past and it didn't play nice with cmake. ctest should work better with cmake.

GenericFrameModelState to stand alone obj

The GenericLs model separates model state into its own class with a defined interface. The generic frame does not and we have duplicative code in the frame plugin and frame model. The state information should be refactored out of the model/plugin and into its own class.

Add support for variable ephemeris rates in line scan model

Many line scan cameras such as HRSC and Dawn VIRS do not scan at a fixed rate. The current line scane camera model assumes that the ephemeri are sampled at a constant rate. For variable rate line scan cameras we should sample the ephemeri are the same rate as the lines.

Master/Dev

Split the repo into master/dev where we push both a release CSM to anaconda and a _dev release.

Generic line scan camera's ground to image iteration is very inefficient

The generic line scan camera uses Newton's method to calculate sample and line. Looking at some of the literature on this problem, that looks like a possibly poor method.

See:
https://www.asprs.org/wp-content/uploads/pers/1993journal/may/1993_may_655-661.pdf
https://www.asprs.org/wp-content/uploads/pers/2001journal/april/2001_apr_449-452.pdf
https://www.asprs.org/wp-content/uploads/pers/2009journal/september/2009_sep_1059-1067.pdf

We should at the very least switch to solving for line (down-track) and then sample (across-track). ISIS uses a bisecting window search method, that we should consider implementing.

Fix windows builds

It looks like the windows builds are going to need some additional flags due to how MS wants DLLs handled.

Example error: 'UsgsAstroFramePlugin::m_registeredPlugin': definition of dllimport static data member not allowed

StackOverflow discussion of this issue.

Add support for variable line scan rates

Many cameras such as HRSC have variable line scan rates. The current line scan camera model is setup for constant line scan rates. In order to support HRSC and other variable rate cameras, we need to add the ability to compute the image time from a table/list/vector/etc. of line scan rates.

script to convert ISD back to SPICE

To help test different ISD metadata creators (e.g. JPL), can we create a script to convert ISD back to SPICE (for a single image).

Remove unused enum in UsgsAstroISD.h ?

The IsdKeywords enum doesn't seem to be actually used anywhere (everything compiles and there are no test failures when this is commented out.) It contains an (unnecessary?) additional list of the ISD keywords that we'd need to keep updated.

Travis Needs to update submodule

See the appveyor.yml for how to do this.

Unsupported methods

A number of the methods in MdisSensorModel.cpp are not implemented, i.e they thow errors. Some of these methods are required to be "actually" implemented.

Use of const reference for basic data types

Some compilers don't optimize well when presented with const references to basic data types ( int, double) instead of just values.

For consistency with other methods in csm, I would suggest the following change

MdisSensorModel.h

current
void losEllipsoidIntersect (const double& height,const double& xc,
const double& yc, const double& zc,
const double& xl, const double& yl,
const double& zl,
double& x,double& y, double& z) const;

suggestion
void losEllipsoidIntersect (double height
,double xc,double yc, double zc,
double xl,double yl,double zl,
double& x,double& y, double& z) const;

categorize ISIS3 calls really needed by camera, spice, other

ISIS3 Camera functions in no particular order

• RA - Sensor::computeRaDec()
• DEC - Sensor::computeRaDec()
• Radii - Target::radii
• Planetocentric Lat (Universal Lat) - Target->Shape->surfaceIntersection->SurfacePoint::GetLatitude
• Planetographic Lat - Get radii, get universal lat, TProjection::ToPlanetographic
• Positive East 360 Lon (Universal Lon) - Target->Shape->surfaceIntersection->SurfacePoint::GetLongitude
• Positive East 180 Lon - Get universal lon, TProjection::To180Domain
• Positive West 360 Lon - Get universal lon, TProjection::ToPositiveWest
• Positive West 180 Lon - Get positive west 360, TProjection::To180Domain
• Body Fixed X,Y,Z - Target->Shape->SurfactPoint::GetX/Y/Z
• Local Radius - Target->Shape->SurfactPoint::GetLocalRadius
• Pixel Resolution - PixelResolution->GetLine/SampleResolution()->Camera::DetectorResolution
• Line Resolution - Camera::DetectorResolution * DetectorMap::LineScaleFactor
• Sample Resolution - Camera::DetectorResolution * DetectorMap::SampleScaleFactor
• Detector Resolution - Camera::DetectorResolution
• Spacecraft Position - SpiceRotation::ReferenceVector
• Spacecraft Azimuth - Camera::SpacecraftAzimuth(Spice::subSpacecraftPoint, Camera::ComputeAzimuth)
• Slant Distance - Sensor::SlantDistance
• Target Center Distance - Spice::targetCenterDistance
• Subspacecraft Lat - Spice::subSpacecraftPoint
• Subspacecraft Lon - Spice::subSpacecraftPoint
• Spacecraft Altitude - Sensor::SpacecraftAlititude
• OFFNADIR Angle - Camera::OffNadirAngle
• Subspacecraft Ground Azimuth - Camera:GroundAzimuth
• Sun Position - Spice::sunPosition
• Subsolar Azimuth - Camera::SolarAzimuth(Spice::subSolarPoint, Camera::ComputeAzimuth)
• Solar Distance - Sensor::SolarDistance
• Subsolar Lat - Spice::subSolarPoint
• Subsolar Lon - Spice::subSolarPoint
• Subsolar Ground Azimuth - Camera::GroundAzimuth
• Phase - ShapeModel::phaseAngle
• Emission - ShapeModel::emissionAngle
• Incidence - ShapeModel::incidenceAngle
• Local Phase - Camera::LocalPhotometricAngles
• Local emission - Camera::LocalPhotometricAngles
• Local Incidence - Camera::LocalPhotometricAngles
• North Azimuth - Get universal lat, Camera::ComputeAzimuth
• Distorted Focal Plane X, Y, Z - Camera::FocalPlaneMap->FocalPlaneMap::FocalPlaneX/Y
• Undistorted Focal Plane X, Y, Z - Camera::DistortionMap->UndistortedFocalPlaneX/Y/Z
• Ephemeris Time - Spice::time
• UTC - Spice::time
• Local Solar Time - Sensor::LocalSensorTime
• Solar Longitude - Spice::computeSolarLongitude

Targeted Unit Testing for Sensor Functionality (EPIC)

This needs to be decomposed into sub-issues. Broadly, the sensor model should be being tested using synthetic information (metadata) in isolation using some testing framework.

Remove python wrapper, usgscam

The python wrapper in USGSCAM is wrapping our implementation headers. What should really be happening is the cycsm python wrapper loads our plugin library at run time. This way the python wrapper is using the CSM api, not our api.

Introduction to CSM

To help get familiar with CSM:

• check out the resources wiki page
• Fork this repo, write a pytest for CSM (see pytest tutorials, also reference tests here, autocnet, pysat)
• Play with Jupyter notebook. See here and wiki for examples. Optional: play with python rendering
• Review existing camera models: MDIS, Pushbroom (CTX, HiRISE, LROC NAC), O-Rex, Cassini NAC/WAC
• Models carry around "state" (ISD keywords). Some overlap in ISD between Frame and Pushbroom - how can we standardize them?
• Begin researching un-supported camera models in CSM (Apollo Metric, Viking, MiniRF (SAR), Magellan (SAR).
• pushframes - LRO WAC, THEMIS VIS

Removed unused variables / code from `UsgsAstroFrameSensorModel`

For example, we require a boresight as input and then never use it.

Update LineScan

The LineScan Sensor model needs to be updated for the ISD specification updates.

• remove unused ISD keywords
• update the def
• update to use JSON

Windows Build

Right now the windows build is failing due to DLL linking issues. This is either a problem in this repo or (more likely) a problem with how the DLLs are being build in the CSM-CyCSM repository. The CSM (C++ API) and Cy-CSM (Python wrapper) are currently being build via appveyor and push to anaconda cloud.

Acceptance Criteria

• py.test run on a windows laptop of libcsm/cycsm/usgscam stack
• appveyor builds of the three repos
• conda installation and py.test run in a conda env

update to socetframesettings

During the write of the ISD (keywords.lis) file we need to add two more keywords. These make sense to be towards the top of the file - perhaps just under "SENSOR_TYPE" and "SENDOR_MODE". The two keywords are:

SEMI_MAJOR_AXIS
ECCENTRICITY

Perhaps some pseudo code. I have no idea if this is the correct method to grab equatorial and polar radii from a level 0 or 1 cube.

    if (mapping.hasKeyword("EquatorialRadius") && mapping.hasKeyword("PolarRadius")) {
      m_equatorialRadius = new Distance(toDouble(mapping["EquatorialRadius"][0]),
                                        Distance::Meters);
      m_polarRadius = new Distance(toDouble(mapping["PolarRadius"][0]),
                                   Distance::Meters);
    }
    else {
      try {
        PvlGroup radiiGrp = Target::radiiGroup(mapping["TargetName"][0]);
        m_equatorialRadius = new Distance(toDouble(radiiGrp["EquatorialRadius"][0]),
                                          Distance::Meters);
        m_polarRadius = new Distance(toDouble(radiiGrp["PolarRadius"][0]),
                                     Distance::Meters);
      }
      catch (IException &e) {
        QString msg = "Unable to grab radii from cube.";
        throw IException(e, IException::Unknown, msg, _FILEINFO_);
      }
    }

     m_eccentricity = 1.0 -
                      (m_polarRadius * m_polarRadius) /
                      (m_equatorialRadius * m_equatorialRadius);
     m_eccentricity = sqrt(m_eccentricity);

so:
SEMI_MAJOR_AXIS m_equatorialRadius
ECCENTRICITY m_eccentricity

e.g. Mars
RECTIFICATION_TERMS
3.00000000000000e+04 0.00000000000000e+00 1.00000000000000e+00
1.00000000000000e+04 1.00000000000000e+00 0.00000000000000e+00
GROUND_ZERO 4.27444857125941e-01 -3.26805190989393e-01 0.00000000000000e+00
LOAD_PT 4.27444857125941e-01 -3.26805190989393e-01 0.00000000000000e+00
COORD_SYSTEM 1
IMAGE_MOTION 0
SENSOR_TYPE USGSAstroLineScanner
SENSOR_MODE UNKNOWN
SEMI_MAJOR_AXIS 3.39619000000000e+006
ECCENTRICITY 1.08339143554195e-001
...

Need a C++ driver function similar to pinhole.cpp to hack with

update to socetlinescankeywords

During the write of the ISD (keywords.lis) file we need to add two more keywords. These make sense to be towards the top of the file - perhaps just under "SENSOR_TYPE" and "SENDOR_MODE". The two keywords are:

SEMI_MAJOR_AXIS
ECCENTRICITY

Perhaps some pseudo code. I have no idea if this is the correct method to grab equatorial and polar radii from a level 0 or 1 cube.

    if (mapping.hasKeyword("EquatorialRadius") && mapping.hasKeyword("PolarRadius")) {
      m_equatorialRadius = new Distance(toDouble(mapping["EquatorialRadius"][0]),
                                        Distance::Meters);
      m_polarRadius = new Distance(toDouble(mapping["PolarRadius"][0]),
                                   Distance::Meters);
    }
    else {
      try {
        PvlGroup radiiGrp = Target::radiiGroup(mapping["TargetName"][0]);
        m_equatorialRadius = new Distance(toDouble(radiiGrp["EquatorialRadius"][0]),
                                          Distance::Meters);
        m_polarRadius = new Distance(toDouble(radiiGrp["PolarRadius"][0]),
                                     Distance::Meters);
      }
      catch (IException &e) {
        QString msg = "Unable to grab radii from cube.";
        throw IException(e, IException::Unknown, msg, _FILEINFO_);
      }
    }

     m_eccentricity = 1.0 -
                      (m_polarRadius * m_polarRadius) /
                      (m_equatorialRadius * m_equatorialRadius);
     m_eccentricity = sqrt(m_eccentricity);

so:
SEMI_MAJOR_AXIS m_equatorialRadius
ECCENTRICITY m_eccentricity

e.g. Mars
RECTIFICATION_TERMS
3.00000000000000e+04 0.00000000000000e+00 1.00000000000000e+00
1.00000000000000e+04 1.00000000000000e+00 0.00000000000000e+00
GROUND_ZERO 4.27444857125941e-01 -3.26805190989393e-01 0.00000000000000e+00
LOAD_PT 4.27444857125941e-01 -3.26805190989393e-01 0.00000000000000e+00
COORD_SYSTEM 1
IMAGE_MOTION 0
SENSOR_TYPE USGSAstroLineScanner
SENSOR_MODE UNKNOWN
SEMI_MAJOR_AXIS 3.39619000000000e+006
ECCENTRICITY 1.08339143554195e-001
...

Linkers

Help getting build to work better.

MdisPlugin methods

The model family name being returned by MdisPlugin is incorrect.

Current code

std::string MdisPlugin::getModelFamily(size_t modelIndex) const {
return "Raster";
}

This should actually be "GeometricRaster" if the model being returned is a RasterGM... See RasterGM.h and GeometricModel.h for details.

I think there may be a misunderstanding of "state" Construction of a model from a "state" is not supposed to be optional. It looks like the support data you construct from could easily be written out and read back in... this would be the "state"... simply a way of persisting the information necessary to instantiate a model... The method canModelBeConstructedFromState() is not implying doing so is optional, but rather is asking if a model can be constructed from the "specific" state being passed in.

Switch from cython based build to a cmake build

In order to better work with a c++ testing framework we should switch to using cmake to build the library.

What do we deliver?

Should we make our headers (UsgsAstroLsSensorModel.h, etc.) available?

This is basically a plugin. How do we create that with cmake?

ISD scheme "required" keys needs to match the schema keys