Filling Out the Imaging Instrument State Parameters Class

The Imaging_Instrument_Parameters class contains attributes describing the dynamic physical or operating characteristics of an instrument.

<azimuth_fov>

OPTIONAL

<elevation_fov>

OPTIONAL

<camera_serial_number>

OPTIONAL

<detector_first_line>

OPTIONAL

<detector_first_sample>

OPTIONAL

<detector_lines>

OPTIONAL

<detector_to_image_rotation>

OPTIONAL

<gain_mode_id>

OPTIONAL

This attribute has no defined standard values.

<instrument_mode_id>

OPTIONAL

This attribute has no defined standard values.

<offset_mode_id>

OPTIONAL

This attribute has no defined standard values and is actually defined as an integer, not a character string (not consistent with "ID").

This attribute is repeatable. What does it mean to repeat it?

<Command_Parameters>

OPTIONAL

Is the intention that each occurrence of this class should correspond to one command? Why is this a property of an image generally, and not something that would be documented in a mission dictionary? Is there a standard set of commands that all spacecraft use? If so, is there an analog for groundbased telescope commanding?

<name>

OPTIONAL

Name of what?

<description>

OPTIONAL

<command_sequence_number>

OPTIONAL

<detector_erase_count>

OPTIONAL

<Auto_Exposure_Parameters>

OPTIONAL

Is it really necessary to repeat the class name in each one of its attributes? What is the ground-based analog for telescope imagery?

<auto_exposure_data_cut>

OPTIONAL

<auto_exposure_max_iteration_count>

OPTIONAL

The definition for this attribute makes it sound like it is an attribute of a specific instrument, not of the data product.

<auto_exposure_percent>

OPTIONAL

It's not clear if this has implications for the other exposure metadata elsewhere in this label, especially if the value is less than 100.

<auto_exposure_pixel_fraction>

OPTIONAL

This attribute appears to require that <auto_exposure_data_cut> also be present, but there is no such constraint in either the schema or Schematron files.

<Exposure_Parameters>

OPTIONAL

This class is identical to that in the <Imaging_Parameters> class, which appears previously in the label. How can these have different content?

<Data_Correction>

OPTIONAL

This class is identical to that in the <Imaging_Parameters><Data_Correction_Parameters> class, which appears previously in the label. How can these have the same definition but different content?

<Telemetry_Parameters>

OPTIONAL

This class description even says its content is "used primarily during mission operations". Why is this in a general imaging dictionary? What are the ground-based, balloon-based, sounding-rocket, and aircraft-based imagery equivalents?

<command_source_id>

OPTIONAL

<download_priority>

OPTIONAL

The definition for this attribute does not indicate whether low numbers or high numbers correspond to "high" priority.

<earth_received_start_date_time>

OPTIONAL

<earth_received_stop_date_time>

OPTIONAL

<flight_software_version_id>

OPTIONAL

<image_data_size>

OPTONAL

This attribute gives no indication of how "size" should be measured and no required units of measure.

<product_completion_status>

OPTIONAL

There are no standard values defined for this attribute.

<surface_gravity>

OPTIONAL

How is this an imaging or telemetry parameter?!?

<telemetry_application_id>

OPTIONAL

<telemetry_application_name>

OPTIONAL

<telemetry_application_subtype_id>

OPTIONAL

<telemetry_provider_id>

OPTIONAL

<telemetry_source_name>

OPTIONAL

<telemetry_transport_protocol>

OPTIONAL

Values: CFDP, Data Product, SFDU

<Error_Pixel>

OPTIONAL

The attributes of this class are all optional. Seems like they should all be required - how else can you specify a pixel?

<line>

OPTIONAL

<sample>

OPTIONAL

<Packet_Parameters>

OPTIONAL

<creation_sclk>

OPTIONAL

<creation_date_time>

OPTIONAL

The definition of this field says it is in UTC, but the data type does not require UTC.

<expected_packets>

OPTIONAL

<received_packets>

OPTIONAL

<missing_packet_flag>

OPTIONAL

<packet_map_mask>

OPTIONAL

The definition of this field says it can be either "a binary or hexadecimal number". This is not possible under PDS4 - it must be one or the other. It is defined as hexadecimal, and since there is no syntactic indication of numeric base, this can only contain hex numbers.

<Instrument_Device_Temperature>

OPTIONAL

<Instrument_Device_Temperature_Index>

REQUIRED

This class contains a choice list in which every element has minOccurs=0. (Problem with LDDTool?)

<name>

REQUIRED

Name of what?

<raw_count>

OPTIONAL

This is a generic attribute which, according to its definition, "may or may not be unitless". This is inconsistent with best practices and conventions established for the PDS core namespace.

<temperature_value>

OPTIONAL

This attribute is both optional and nillable. This is inconsistent with PDS core conventions.

<Instrument_Device_Voltage>

OPTIONAL

<Instrument_Device_Voltage_Index>

REQUIRED

<name>

REQUIRED

Name of what?

<voltage_value>

REQUIRED