Skip to content

ALE 1.0 Design

Jump to bottom
Jesse Mapel edited this page Aug 16, 2019 · 3 revisions

For the 1.0 release of ALE, we are moving to a slightly different design for the Python module.

Overall Structure

Drivers will be responsible for homogenizing the data and new formatting functions will format the data in a driver for a specific type of sensor model. In addition, the load and loads methods will intelligently select the driver to use instead of the current brute force approach.

Example Usage

import ale, pvl, json

label = pvl.load('EW0031509051D.IMG`)

# Manually selecting a driver
with ale.MessengerDrivers.MDISSpicePDS3(label) as driver:
    usgscsm_isd = ale.to_usgscsm(driver)

# Using ale.loads
usgscsm_isd = ale.loads(label, format='usgscsm')

# Using ale.load
usgscsm_isd = ale.load('EW0031509051D.IMG`, format='usgscsm')

with open('EW0031509051D.json', 'w') as fh:
    json.dump(usgscsm_isd, fh)

Drivers

The driver structure is remaining largely the same as before. There will be a single base Driver class that all of the drivers inherit from. There will also be various mix-ins for different data sources such as PDS3 labels, PDS4 labels, and SPICE kernels. Unlike before 1.0, the mix-in class hierarchy will be completely flat and the base Driver class will be an abstract base class. This way, the formatting functions can use the interface of the abstract base class regardless of the driver and we avoid multiple inheritance issues.

The base Driver class

The abstract base class for all of the drivers is fittingly called Driver. It requires the following interface:

  • frame_chain - Get the frame rotation chain from the target body reference frame to the sensor reference frame
  • sensor_position - Get the position of the sensor relative to the target
  • sun_position - Get the position of the sun relative to the target
  • ephemeris_start_time - Get start ephemeris time for an image
  • ephemeris_stop_time - Get stop ephemeris time for an image
  • ephemeris_center_time - Get the center ephemeris time for an image. This is not abstract and is implemented as the average of the ephemeris start and ephemeris stop time
  • image_lines - Get the number of lines in the image
  • image_samples - Get the number of samples in the image
  • sensor_frame_id - Get the NAIF ID of the sensor reference frame
  • target_frame_id - Get the NAIF ID of the target body
  • target_name - Get the name of the target
  • sensor_name - Get the name of the sensor
  • platform_name - Get the name of the platform that the sensor is on. Usually this will be a spacecraft
  • sample_summing - Get the number of detector samples summed to produce each image sample
  • line_summing - Get the number of detector lines summed to produce each image line
  • detector_start_sample - Get the detector sample corresponding to the first image sample. This is not abstract and returns 0
  • detector_start_line - Get the detector line corresponding to the first image line. This is not abstract and returns 0
  • isis_naif_keywords - Get the dictionary of keywords and values that ISIS creates and attaches to the label
  • sensor_model_version - Get version number of the sensor model the driver works with
  • focal_length - Get the focal length of the sensor
  • focal2pixel_lines, focal2pixel_samples, pixel2focal_x, and pixel2focal_y - Get the detector to focal plane transformations
  • target_body_radii - Get the target body triaxial radii
  • detector_center_line - Get the detector sample of the principal point
  • detector_center_sample - Get the detector line of the principal point
  • usgscsm_distortion_model - Get the USGSCSM distortion model

Some of the mix-in classes require attributes, such as a label. To avoid concerns with which constructor gets called, the Driver class constructor will take a props argument that is a dictionary of attributes the mix-ins will require. The attributes can then be accessed by self.props['attribute name'].

Mix-Ins

With the 1.0 architecture, the existing mix-ins are being more clearly delineated. The mix-in classes are being changed so that they do not inherit from anything. This ensures we do not have issues with diamond inheritance in the final driver classes. We are also defining loose categories for the mix-ins, so that it is clearer which mix-ins should be combined together and which should not.

Label mix-ins

The following are mix-ins that handle label data:

  • PDS3Label
  • PDS4Label
  • ISISLabel

They are responsible for providing the following information:

  • target_name
  • image_lines
  • image_samples
  • line_summing
  • sample_summing
  • spacecraft_clock_start_count
  • spacecraft_clock_stop_count
  • utc_start_time
  • utc_stop_time
  • exposure_duration

Auxiliary data mix-ins

The following are mix-ins that handle auxiliary data:

  • NaifSpice
  • IsisSpice

They are responsible for providing the following information:

  • sensor_position
  • sun_position
  • detector_center_sample
  • detector_center_line
  • focal_length
  • focal2pixel_lines
  • focal2pixel_samples
  • pixel2focal_x
  • pixel2focal_y
  • target_body_radii
  • ephemeris_start_time
  • frame_chain
  • isis_naif_keywords - This includes only the keywords common to all ISIS3 sensor models. All concrete drivers will need to override this.

Distortion mix-ins

The following are mix-ins that handle distortion models

  • RadialDistortion
  • NoDistortion

Any instrument specific distortion model should be implemented by that instrument's driver.

They are responsible for providing the following information:

  • usgscsm_distortion_model

Sensor type mix-ins

The following are mix-ins that handle what type of sensor a driver is for

  • LineScan
  • Framing

These mix-ins provide the following:

  • ephemeris_time
  • ephemeris_stop_time
  • line_scan_rate

Concrete Drivers

The final class that combines the base driver class and the mix-ins is called the concrete driver. These are the classes that are actually used during the load function to generate meta-data. Generally, each concrete driver class will mix together a label, an auxiliary data source, a sensor type, and a distortion model. This is not strictly required though. In addition, the concrete driver is responsible for implementing anything particular to a specific instrument or data set. For example, the MESSENGER MDIS concrete drivers compute the focal length using the temperature dependent focal length equations and the focal plane temperature.

There are often multiple concrete drivers for each sensor. For example, there are currently 2 concrete drivers for the MESSENGER MDIS sensor. Each different concrete driver works with different data by mixing different mix-ins together. For this reason, we use the following naming convention for concrete drivers:

Driver

Accordingly, the two MESSENGER MDIS drivers are called MessengerMdisPds3NaifSpiceDriver and MessengerMdisIsisLabelNaifSpiceDriver.

The concrete drivers are responsible for providing the following:

  • sensor_name
  • platform_name
  • sensor_model_version
  • isis_naif_keywords
Clone this wiki locally