European Space Agency
Research and Science Support Department
Planetary Missions Division















OMEGA Experiment Archive
Interface Control Document

OME-DU-061-214
Draft 653.21
1523 AprilNovember 20054September 20thApril 14






______________________________
Prepared by:  Instrument Archive Responsible




__________________________
Approved by: Principal Investigator








Institut d’Astrophysique Spatiale
Bâtiment 121, Université Paris XI, 91405 ORSAY Cedex, France.
Centre National de la Recherche Scientifique











This page intentionally left blank.



















	______________________________
	Prepared by:  Instrument Archive Responsible

__________________________
Approved by: Principal Investigator





Distribution ListDISTRIBUTION LIST


Recipient
OrganisationOrganization
Jean-Pierre Bibring
Institut d’Astrophysique Spatial
Yves Langevin
Institut d’Astrophysique Spatial
Michel Berthé
Institut d’Astrophysique Spatial






Joe Zender
RSSD/ESTEC
David Heather
RSSD/ESTEC



















Change LogCHANGE RECORD SHEET


Date
Sections Changed
Reasons for Change















































TBD ITEMS






Table Of ContentsTABLE OF CONTENTS

1 Introduction	1
1.1	Purpose and Scope	1
1.2 Archiving Authorities	1
1.2.1 PDS-D …	1
1.2.2 ESA’s Planetary Science Archive (PSA)	1
1.3 Contents	1
1.4 Intended Readership	1
1.5 Applicable Documents	1
1.6 Relationships to Other Interfaces	1
1.7 Acronyms and Abbreviations	1
1.7 Contact Names and Addresses	1
2 Overview of Process and Product Generation	1
3 Archive Format and Content	1
3.1 Format and Conventions	1
3.1.1 Deliveries and Archive Volume Format	1
3.1.2 Data Set ID Formation	1
3.1.3 Data Directory Naming Convention	1
3.1.4 Filenaming Convention	1
3.2 Standards Used in Data Product Generation	1
3.2.1 PDS Standards	1
3.2.2 Time Standards	1
3.3.3 Reference Systems	1
3.3.4 Other Applicable Standards	1
3.3 Data Validation	1
3.4 Content	1
3.4.1 Volume Set	1
3.4.2 Data Set	1
3.4.3 Directories	1
3.4.3.1 Root Directory	1
3.4.3.2 Calibration Directory	1
3.4.3.3 Catalog Directory	1
3.4.3.4 Index Directory	1
3.4.3.4.1 Dataset Index File, index.lbl and index.tab	1
3.4.3.4.2 Geometric Index File, geoindex.lbl and geoindex.tab	1
3.4.3.4.3 other Index Files	1
3.4.3.5 Browse Directory and Browse Files	1
3.4.3.5  Geometry Directory	1
3.4.3.6 Software Directory	1
3.4.3.7 Gazetter Directory	1
3.4.3.8 Label Directory	1
3.4.3.9 Document Directory	1
3.4.3.10 Extras Directory	1
3.4.3.11 Data Directory	1
3.4.4 Pre-Flight Data Products	1
3.4.5 Sub-System Tests	1
3.4.6 Instrument Calibrations	1
3.4.7 Other Files written during Calibration	1
3.4.8 In-Flight Data Products	1
3.4.0 Software	1
3.4.10 Documentation	1
3.4.11 Derived and other Data Products	1
4. Detailed Interface Specifications	1
4.1 Structure and Organization Overview	1
4.2 Data Sets, Definition and Content	1
4.3 Data Product Design	1
4.3.1 Data Product A Design	1
4.3.1.1 File Characteristics Data Elements	1
4.3.1.2 Data Object Pointers Identification Data Elements	1
4.3.1.3 Instrument and Detector Descriptive Data Elements	1
4.3.1.4 Structure Definition of Instrument Parameter Objects	1
4.3.1.5 Data Object Definition	1
4.3.1.6 Description of Instrument	1
4.3.1.7 Parameters Index File Definition	1
4.3.1.8 Mission Specific Keywords	1
4.3.2 Data Product B Design	1
		[ add your chapters as needed]	1
1.	Appendix: Available Software to read PDS files	1
2.	Appendix: Auxiliary Data Usage	1
3.	Appendix: Example of Directory Listing of Data Set X	1
1 Introduction	5
1.1	Purpose and Scope	5
1.2 Contents	5
1.3 Intended Readership	5
1.4 Applicable Documents	5
1.5 Relationships to Other Interfaces	5
1.6 Acronyms and Abbreviations	5
1.7 Contact Names and Addresses	5
2 Overview of Process and Product Generation	6
3 Archive Format and Content	6
3.1 Format	6
3.1.1 Volume Format	6
3.1.2 Data Set Naming Conventiont	6
3.1.3 Filenaming Convention 	6
3.2 Standards Used in Data Product Generation	6
3.2.1 PDS Standards	7
3.2.2 Time Standards	7
3.3.3 Coordinate Systems	7
3.3 Data Validation	7
3.4 Content	7
3.4.1 Volume Set	7
3.4.2 Data Set	7
3.4.3 Directories	7
3.4.3.1 Root Directory	8
3.4.3.2 Calibration Directory	8
3.4.3.3 Catalog Directory	8
3.4.3.3.1 Mission Catalog File 	[to be copied from ESA]	8
3.4.3.3.2 Mission Host Catalog File 	[to be copied from ESA]	8
3.4.3.3.3 Host Instrument Catalog File	8
3.4.3.3.4 Instrument Catalog File	8
3.4.3.3.5 Personnel Catalog File	8
3.4.3.3.6 Reference Catalog File	8
3.4.3.3.7 Dataset Catalog File	8
3.4.3.3.8 Map Projections Catalog File	8
3.4.3.3.9 Targets Catalog File	8
3.4.3.4 Index Directory	8
3.4.3.4.1 Dataset Index File, index.lbl and index.tab	8
3.4.3.4.2 Geometric Index File, geoindex.lbl and geoindex.tab	8
3.4.3.4.3 other Index Files	8
3.4.3.5 Browse Directory and Browse Files	8
3.4.3.5  Geometry Directory	8
3.4.3.6 Software Directory	8
3.4.3.7 Gazetter Directory	9
3.4.3.8 Label Directory	9
3.4.3.9 Document Directory	9
3.4.3.10 Extras Directory	9
3.4.3.11 Data Directory	9
3.4.4 Data and Label Files	9
3.4.5 Pre-Flight Data Products	9
3.4.6 Sub-System Tests	9
3.4.7 Instrument Calibrations	9
3.4.8 Other Files written during Calibration	9
3.4.9 In-Flight Data Products	10
3.4.10 Software	10
3.4.11 Documentation	10
3.4.13 Derived and other Data Products	10
4. Detailed Interface Specifications	10
4.1 Structure and Organization Overview	10
4.3 Data Sets, Definition and Content	11
4.4 Data Product Identification	11
4.5 PDS Label Structure, Definition and Format	11
4.6 Overview of Detectors	11
4.6.1 Detector A data level X	11
4.6.1.1 File Characteristics Data Elements	11
4.6.1.2 Data Object Pointers Identification Data Elements	11
4.6.1.3 Instrument and Detector Descriptive Data Elements	12
4.6.1.4 Structure Definition of Instrument Parameter Objects	12
4.6.1.5 Data Object Definition	12
4.6.1.6 Description of Instrument	12
4.6.1.7 Parameters Index File Definition	12
4.6.1.8 Mission Specific Keywords	12
4.6.2 Detector B data level Y	12
4.6.2.1 File Characteristics Data Elements	12
4.6.2.2 Data Object Pointers Identification Data Elements	12
4.6.2.3 Instrument and Detector Descriptive Data Elements	12
4.6.2.4 Structure Definition of Instrument Parameter Objects	12
4.6.2.5 Data Object Definition	12
4.6.2.6 Description of Instrument	12
4.6.2.7 Parameters Index File Definition	12
4.6.2.8 Mission Specific Keywords	12
1.	Appendix: Available Software to read PDS files	12
2.	Appendix: Auxilliary Data Usage	12
3.	Appendix: Example of Directory Listing of Data Set X	12

1	Introduction	3
1.1	Purpose and Scope	3
1.2	Archiving Authorities	3
1.3	Contents	3
1.4	Intended Readership	3
1.5	Applicable Documents	3
1.6	Acronyms and Abbreviations	4
1.7	Contact Names and Addresses	4
2	Overview of Scientific Objectives, Instrument Design, Data Handling Process and Product Generation	5
2.1	Scientific Objectives	5
2.2	Instrument Design	5
2.3	Data Handling Process	8
2.4	Overview of data products	10
2.4.1	Pre-Flight Data Products	10
2.4.2	Sub-System Tests	10
2.4.3	Instrument Calibrations	10
2.4.4	Other Files written during Calibration	10
2.4.5	In-Flight Data Products	10
2.4.6	Software	11
2.4.7	Documentation	11
2.4.8	Ancillary Data Usage	11
3	Archive Format and Content	14
3.1	Format and Conventions	14
3.1.1	Deliveries and Archive Volume Format	14
3.1.2	Data Set ID Formation	14
3.1.3	Data Set Directory Structure	14
3.1.4	File Naming Convention	14
3.2	Standards Used in Data Product Generation	14
3.2.1	PDS Standards	14
3.2.2	Time Standards	14
3.2.3	Cartographic Standards	15
3.2.4	Other Applicable Standards	15
3.3	Data Validation	15
3.4	Data Set Directories Content	16
3.4.1	Root Directory	16
3.4.2	Catalog Directory	16
3.4.3	Index Directory	17
3.4.4	Software Directory	17
3.4.5	Document Directory	18
3.4.6	Data Directory	18
4	Detailed Interface Specifications	20
4.1	Data Product Design	20
4.1.1	Science Level-1B Data Product	20
4.1.2	Geometry Level-1B Data Product	26
5	Appendix A: Geometrical Parameters Definition	31
6	Appendix B: Example of PDS label of an OMEGA 1B data product	33
7	Appendix C: Example of PDS label of a level-1B geometry data product	35
8	Appendix D: PDS Glossary	37
1	Introduction	3
1.1	Purpose and Scope	3
1.2	Archiving Authorities	3
1.3	Contents	3
1.4	Intended Readership	3
1.5	Applicable Documents	3
1.6	Acronyms and Abbreviations	4
1.7	Contact Names and Addresses	5
2	Overview of Scientific Objectives, Instrument Design, Data Handling Process and Product Generation	6
2.1	Scientific Objectives	6
2.2	Instrument Design	6
2.3	Data Handling Process	9
2.4	Overview of Data Products	12
2.4.1	Pre-Flight Data Products	12
2.4.2	Sub-System Tests	12
2.4.3	Instrument Calibrations	12
2.4.4	Other Files written during Calibration	12
2.4.5	In-Flight Data Products	12
2.4.6	Software	13
2.4.7	Documentation	13
2.4.8	Derived and other Data Products	13
2.4.9	Ancillary Data Usage	14
3	Archive Format and Content	16
3.1	Format and Conventions	16
3.1.1	Deliveries and Archive Volume Format	16
3.1.2	Data Set ID Formation	16
3.1.3	Data Set Directory Structure	16
3.1.4	File Naming Convention	16
3.2	Standards Used in Data Product Generation	17
3.2.1	PDS Standards	17
3.2.2	Time Standards	17
3.2.3	Cartographic Standards	17
3.2.4	Other Applicable Standards	18
3.3	Data Validation	18
3.4	Data Set Directories Content	18
3.4.1	Root Directory	18
3.4.2	Catalog Directory	19
3.4.3	Index Directory	19
3.4.4	Software Directory	20
3.4.5	Document Directory	20
3.4.6	Data Directory	21
4	Detailed Interface Specifications	22
4.1	Data Product Design	22
4.1.1	Science Level-1B Data Product	22
4.1.2	Geometry Level-1B Data Product	29
5	Appendix A: Geometrical Parameters Definition	35
6	Appendix B: Example of PDS label of an OMEGA 1B data product	37
7	Appendix C: Example of PDS label of a level-1B geometry data product	39
8	Appendix D: PDS Glossary	41






1.5	Scientific Objectives	3
56677889

2. 32431	Introduction	
1.1	Purpose  and Scope	
1.2	Archiving Authorities	
1.3	Contents	
1.4	Intended Readership	
1.5	Scientific Objectives	
1.6	Applicable Documents	
1.7	Relationships to Other Interfaces	
1.8	Acronyms and Abbreviations	
1.9	Contact Names and Addresses	
2	Overview of Instrument Design, Data Handling Process and Product Generation	
2.1	Scientific Objectives	
2.2	Data Handling Process	
2.3	Product Generation	
2.4	Overview of Data Products	
2.4.1	Pre-Flight Data Products	
2.4.2	Sub-System Tests	
2.4.3	Instrument Calibrations	
2.4.4	Other Files written during Calibration	
2.4.5	In-Flight Data Products	
2.4.6	Software	6
2.4.7	Documentation	
2.4.8	Derived and other Data Products	
2.4.9	Ancillary Data Usage	
3	Archive Format and Content	
3.1	Format and Conventions	
3.1.1	Deliveries and Archive Volume Format	
3.1.2	Data Set ID Formation	
3.1.3	Data Directory Naming Convention	
3.1.4	Filenaming Convention	
3.2	Standards Used in Data Product Generation	
3.2.1	PDS Standards	8
3.2.2	Time Standards	8
3.2.3	Reference Systems	8
3.2.4	Other Applicable Standards	8
3.3	Data Validation	
3.4	Content	
3.4.1	Volume Set	
3.4.2	Data Set	
3.4.3	Directories	
4	Detailed Interface Specifications	
4.1	Structure and Organization Overview	
4.2	Data Sets, Definition and Content	
4.3	Data Product Design	
4.3.1	Data Product A Design	
4.3.2	Data Product B Design	
4	Appendix: Available Software to read PDS files	
5	
6	Appendix: Example of Directory Listing of Data Set X	




TABLE OF FIGURES

Figure 1: Data Set Directory Structure	1416
Figure 2: Conceptual view of the Science Data Qube	2426
Figure 3: View of a geometry data product	2629
Figure 4: Conceptual view of the Geometry Data Qube	3034
Figure 5: Overview of pixel observation geometry	3135






TABLE OF TABLES

Table 1: Data Level Definition	89
Table 2: SPICE kernels used in Data Processing	1315
Table 3: File Naming Convention	1416
Table 4: Science Data Qube Keywords Definition.	2325
Table 5: Geometry Qube Keywords Definition.	2932
Table 6: Geometry Data Qube Parameters Description	3034






1 

1 
1 Introduction
1.1 Purpose  andPurpose and Scope
 Purpose and Scope

The purpose of this EAICD (Experimenter to (Planetary Science) Archive Interface Control Document) is two fold. First it provides users of the [your instrument name] instrument with detailed description of the product and a description of how it was generated, including data sources and destinations. Secondly, it is the official interface between your instrument team and your archiving authority. 
The purpose of this EAICD (Experimenter to Planetary Science Archive Interface Control Document) is twofold. First it provides users of the OMEGA instrument with detailed description of the product and a description of how it was generated, including data sources and destinations. Secondly, the EAICD describes the interface to the Planetary Science Archive (PSA) of ESA and is the official document between each experimenter team and the PSA.
1.1 the EAICD describes the interface to the Planetary Science Archive (PSA) of ESA and is the official document between each experimenter team and the PSA.
1.2  Archiving Authorities

The Planetary Data System Standard is used as archiving standard by:
* NASA for U.S. planetary missions, implemented by PDS
* ESA for European planetary missions, implemented by the Research and Scientific Support Department (RSSD) of ESA

ESA’s Planetary Science Archive (PSA)
ESA implements an online science archive, the PSA  
* to support and ease data ingestion
* to offer additional services to the scientific user community and science operations teams as e.g.:
o search queries that allow searches across instruments, missions and scientific disciplines
o several data delivery options as:
* direct download of data products, linked files and data sets
* ftp download of data products, linked files and data sets
The PSA aims for online ingestion of logical archive volumes and will offer the creation of physical archive volumes on request.

















The Planetary Data System Standard is used as archiving standard by
* NASA for U.S. planetary missions, implemented by PDS
* ESA for European planetary missions, implemented by the Research and Scientific Support Department (RSSD) of ESA
1.1.1 1.2.1 PDS-D …
1.1.1 1.2.2 ESA’s Planetary Science Archive (PSA)
		ESA implements an online science archive, the PSA, 
* to support and ease data ingestion
* to offer additional services to the scientific user community and science operations teams as e.g.
o search queries that allow searches across instruments, missions and scientific disciplines
o several data delivery options as
* direct download of data products, linked files and data sets
* ftp download of data products, linked files and data sets
The PSA aims for online ingestion of logical archive volumes and will offer the creation of physical archive volumes on request.
1.3 Contents

This document describes the data flow of the [your instrument name] instrument on [mission name] from the s/c until the insertion into the PDS-D for NASA athe nd PSA for ESA. It includes information on how data were processed, formatted, labeled and uniquely identified. The document discusses general naming schemes for data volumes, data sets, data and label files. Standards used to generate the product are explained. Software that may be used to access the product are is explained furtheron.
The design of the data set structure and the data product is given. Examples of these are given in the appendix.This document describes the data flow of the OMEGA instrument on Mars Express from the s/c until the insertion into the PSA for ESA. It includes information on how data were processed, formatted, labeled and uniquely identified. The document discusses general naming schemes for data volumes, data sets, data and label files. Standards used to generate the product are explained. Software that may be used to access data product is explained.
The design of the data set structure and the data product is given. Examples of these are given in the appendix.
1.4  Intended Readership

The staff of the archiving authority (Planetary Data System for NASA, (Planetary Science Archive, ESA, RSSD,  for ESA) the Planetary Science Archive design team) and any potential user of the [your instrument name]OMEGA data.
1.1 Scientific Objectives
1.1 what about the section ?
1.5 Applicable Documents

[1] Planetary Data System Data Preparation Workbook, February 17, 1995, Version 3.1, JPL, D-7669, Part1

[2] Planetary Data System Standards Reference, June August 1, 20031999, Version 3.63, JPL, D-7669, Part 2

[3] Mars Express [Mission] Archive Generation, Validation and Transfer Plan, 2001 June 21[month day, year], ESA-MEX-TN-4009

[4] OMEGA Flight User Manual: OME-DU-0023-118-IAS, Version 3.0

[5] Report of the IAU/IAG working group on cartographic coordinates and rotational elements of the planets and satellite: 2000, P.K. Seidelman, et al., Celestial Mechanics and Dynamical Astronomy, in Press, 2002. 

[6] Planetary Science Data Archive Technical Note, Geometry and Position Information, 8 October 2004, SOP-RSSD-TN-010, Issue 3 - Revision 3[doc number]
1.1 [reference system: definition document]
1.1 [any other instrument specific documents]
1.1 
1.1 
1.1 
1.1 
1.1 
1.1 Relationships to Other Interfaces
1.1 [state what products, software and documents would be affected by a change in this EAICD. Refer to any other documents that describe the interfaces.]
1.1 
1.1 
1.1 
1.1 
1.1 
1.1 
1.6 Acronyms and Abbreviations
PSA		Planetary Science Archive
AD	Applicable Document
APID	Application Process IDentifier.
CNES	Centre National d’Etudes Spatiales
DESPA	Département de Recherches Spatiales
DN	Digital Number
DDS	Data Delivery System
EAICD	Experiment Archive Interface Control Document
ESA	European Space Agency
ESOC	European Space Operation Center
ESTEC	European Space Research and Technology Center
FOV	Field of View
HK	Housekeeping
IAS	Institut d’Astrophysique Spatiale
IFOV	Instantaneous Field of View
IFSI	Istituto di Fisica dello Spazio Interplanetario
IKI	Institut Kosmitcheski Isledovanie
ISIS	Integrated Software for Imaging Spectrometers
IR	Infrared
OBT	On Board Time
MEX	Mars Express
NAIF	Navigation Ancillary Information Facility
OMEGA	Observatoire pour la Minéralogie, l'Eau, les Glaces et l'Activité
PDS	Planetary Data System
PI	Principal Investigator
PSA	Planetary Science Archive
PVV	PSA Volume Verifier
RD	Reference Document
ROM	Read-Only Memory
S/C	Spacecraft
SCET	Spacecraft Elapsed Time
SWIR	Short Wavelength Infrared channel
TBC	To Be Confirmed
TBD	To Be Defined
VNIR	Visible and Near Infrared channel
WRT	With Respect To

1.1 
1.7 1.7 Contact Names and Addresses

Gilles Poulleau, IAS
Overall responsibility, automatic processing
gilles.poulleau@ias.u-psud.fr
+0033 (0) 1 69 85 86 05

Brigitte Gondet, IAS
Level 1 and 2 products, calibration
brigitte.gondet@ias.u-psud.fr
+0033 (0) 1 69 85 86 35

Yves Langevin, IAS
Software responsibility
yves.langevin@ias.u-psud.fr
+0033 (0) 1 69 85 86 81

Nicolas Manaud, IAS
Geometry products
nicolas.manaud@ias.u-psud.fr
+0033 (0) 1 69 85 86 20

Stephane Erard, IAS
Level-3 and derived products
stephane.erard@ias.u-psud.fr
+0033 (0) 1 69 85 86 41

[specify the institutes and names involved in the data preparation; give at least phone numbers and email addresses]
	[specify the institutes and names involved in the data preparation; give at least phone numbers and email addresses]




1 



[Copy the instrument description from your instrument user manual. Explain at very abstract level what data types map your instrument best.
The instrument description shall describe the instrument design and functionality and shall be understandable by non-team scientists and engineers.]
1 Overview of Scientific Objectives, Instrument Design, Data Handling  Process and Product Generation
2 Overview of Scientific Objectives, Instrument Design, Data Handling Process and Product Generation
1.1 
1.1 
1.1 
1.1 
1.1 
2.1 SSccientific OObjectives

[List scientific objectives from the AO and from the EID-B and show what data will guarantee the scientific return and how it is archived]


The OMEGA mapping spectrometer will map the Martian surface with an IFOV of 1.2 mrad (4.1 arc minutes), and acquire for each resolved pixel the spectrum from 0.36 to 5.2 µm in 352 contiguous spectral channels (spectels) in the nominal mode.
The optical part consists in two co-aligned units, each including a telescope: a Visible Channel (VNIR) analyses the light from 0.36 to 1.07 µm, using as a detector a bi-dimensional CCD THX7863 Thomson detector in a pushbroom mode: 96 spectral lines of 128 columns, imaging at once a crosstrack line of 128 pixels large at the surface of Mars; a Near Infrared Channel, named SWIR (Short Wavelength IR Channel) disperses the light through two spectrometers from 0.93 to 2.7 µm and 2.6 to 5.2 µm, onto two linear InSb arrays (whiskbroom mode) cooled down 70K, each with a dedicated cryocooler. A scanning mirror in front of the SWIR telescope permits to acquire crosstrack swaths of 16 up to 128 pixels width, for a maximum FOV of 8.8°, thus matching the VNIR FOV. SNR of ? 100 over the entire spectral range, for IR integration times of 5 ms per pixel, is the specification.

Combining imagery and spectrometry, OMEGA is designed to provide the mineralogical and molecular composition of the surface and atmosphere of Mars through the spectral analysis of the re-diffused solar light and surface thermal emission. OMEGA will provide a global coverage at medium resolution (1 to 5 km) of the entire surface of Mars from altitudes 1000 to 4000 km, and snapshots of selected areas, amounting to at least a few percents of the surface, with a resolution of a few hundreds meters when observed close to periapsis (300 km altitude). More specifically, with the above-mentioned spatial resolution, OMEGA should allow: 

* to characterize the composition of surface materials, discriminating between the various classes of silicates, hydrated minerals, oxides and carbonates, organic frosts and ices;
* to study the time and space distribution of atmospheric CO2, CO and H2O;
* to identify the aerosols and dust particles in the atmosphere, and observe their time and space distributions
* to monitor the surface dust transportation processes.


2.2 Instrument Design


OMEGA is a mapping spectrometer working both in the visible and the infrared spectral  rangesspectral ranges.

It is constituted of two co-aligned channels, one working in the 0.38 to 1.05 micrometersµm visible and near infrared range (VNIR channel), the other in the 0.93 to 5.1 micrometersµm short wavelength infrared range (SWIR channel). The data products constitute three-dimensional (X, YY, lambda, Ylamda) image-cubes,  with, where X and Y are theith two spatial dimensions and lambda theone spectral dimensionsdimension.
 

The VNIR channel uses a bi-dimensional CCD detector,  operated in a pushbroom mode. Its telescope acquires at once in its focal plane one cross-track line corresponding to the entire 8.8 degrees FOV, defined by an entrance slit; the second dimension of the image is provided by the motion of the S/C. Each line is spectrally dispersed along the columns of the array, the slit being imaged through a concave holographic grating.  

The SWIR channel operates in the whiskbroom mode: each imaged pixel is acquired at once by an IR telescope; a scanning mirror, in front of the telescope, permits to acquire crosstrack swaths of 16 up to 128 pixels width, for a maximum FOV of 8.8 degrees, thus matching the VNIR FOV, while the S/C motion provides the second spatial dimension. The imaged pixel is focused by the telescope on a slit, followed by a collimator. The beam is then split towards two separated spectrometers, to acquire the IR spectrum of each resolved pixel onto two InSb linear arrays of 128 spectels each, from 0.93 to 2.73 micrometersµm and from 2.55 to 5.1 micrometersµm respectively. Each array is cooled down 70K by a dedicated cryocooler, while the entire spectrometer is cooled down 190 K by a conductive link to a passive radiator. The typical IR integration time, defined by the S/C ground track velocity and the spatial sampling chosen, is 5 msec.
The corresponding VNIR integration times are 100 to 800 ms, depending on the swath width, thus the altitude. With such integration times, SNR > 100 are obtained over the full spectral range, over the entire spectral range, is the specification.

OMEGA is made of two distinct units:

*   - a Camera unit (OMEGA-C) with the VNIR and SWIR spectrographs, their associated electrical devices, and one electronics assembly for the control of the camera. All units are integrated onto a common base plate; its mass is 23.8 kg.
*   - a Main Electronics module (OMEGA-ME), for the data processing and the general management of  the instrument; its mass is 5.1 kg.

VNIR spectrograph

VNIR is made of two optical subsystems: a focusing telescope with its focal plane on a slit, and a spectrometer, that spreads the slit image in the spectral dimension. It provides image data  indata   thein the spectral range 0.38 to 1.05 micrometersµm achieving a maximum spatial sampling of 0.4 mrad and a maximum spectral sampling of 50 Angstrom. A refractive telescope focuses the image on a slit placed on the Rowland circle of an aberration corrected concave holographic grating mirror. This element reflects and disperses the light on a CCD detector tangent to the Rowland circle. The detector used is the TH7863 frame transfer CCD produced by Thomson. The chosen grating mirror can create a flat image onto the focal plane. This property allows to match very well the flat detector matrix to the grating, without other optical components. A CCD frame is then composed of N rows each containing an image of the slit at a given wavelength, and M columns each containing the spectrum of a point along the slit. The bi-dimensional image of the surface is obtained by the pushbroom technique, in which the spacecraft movement along its orbit performs a scan of the slit across the planetary surface. The electrical signal from the detector is amplified and then digitized by a fast 12 bit A/D converter; after conversion, all data are processed within the OMEGA-ME.

In order to decrease the detector noise, VNIR is cooled down 190 K by conduction to the SWIR mechanical unit. The choice of refractive over reflective optics was made because of the large (8.8 degrees) field of view requirement.
The telescope has a 6 elements objective similar to that of a modern commercial photographic camera. The shape of the elements and the types of optical glass were chosen to obtain the best chromatic aberration corrections over the entire spectral range. The last element serves as a field lens whichlens, which matches the entire objective with the grating to avoid light losses. To avoid stress in the lenses at the working temperature, the two doublets are not cemented. The two glasses, FK54 and fused silica, have very different expansion coefficients of 8 and 0.55 x 10E-6/K at room  temperatureroom temperature. The entrance aperture of 15.6 mm is defined by a diaphragm between the two doublets. An aberration corrected concave holographic grating is placed 142.7 mm from the entrance   slit (which is in the focal plane of the telescope). The grating is tilted to form the spectrum at an angle of roughly 6 degrees from the optical axis. This angle does not allow CCD insertion near the entrance without beam obscuration; therefore, a folding mirror deflects the beam toward the side of the assembly, where the CCD can be mounted with ample clearance. 

The zero order spectrum, at 4.5 degrees from the folded optical axis (lying in the y-z plane) is directed into a light trap to prevent degradation of the image. The first order spectrum ranges in angle from 6 degrees at lambda lamda = 0.35 micrometersµm to 10 degrees for lambda lamda = 1.05 micrometersµm. The second and higher order spectra can, in principle, also degrade the data. Its contribution depends both on the grating efficiency, and the spectral distribution of the incident radiation. For this reason, a dedicated filter is mounted, in front of the detector. The concave, spherical, holographic grating in a Rowland mounting - where the entrance slit and the spectrum are on radii of curvature of the grating - makes the spectrometer compact, light, and simple. In fact, no collimator or camera lens is required and the spectrometer has only one element.
Moreover, the focal plane image can be flat, to match the planar CCD sensors. Since the concave holographic grating is obtained by recording a perfect optical pattern with groove spacing absolutely constant, it has no ghosts. Stray light has also a much lower level than the best ruled gratings. Therefore, concave holographic gratings generally have a much higher signal to noise ratio than classically ruled gratings.

The optical performances have been computed by ray tracing. In the focal plane the spot diagram is about the pixel size (23x23 microns). For off-axis propagation (4.4 degrees off-axis), the total spot size is about 2 pixels in the sagittal direction. More precisely, on axis and at 0.7 micrometerµms, 98.8 % of the energy falls within a 23x23 micron pixel; at 4.4 degrees off-axis and lambda lamda = 0.4 micrometersµm, 74 % of the energy falls within a CCD element. When the light propagates off-axis, the spot size is smaller for the shorter wavelengths. 

The Pattern Generator (PG) determines the CCD integration time, and generates the timing signals necessary to transfer an image from the light sensitive area to the masked zone and then to the output shift register of the CCD. The output of the CCD is then amplified and converted by a fast 12 bit12-bit A/D converter under control of the PG. The timing of the instrument imposes a relatively high frequency for CCD operation. In fact, depending on the distance from the planet and hence on the spacecraft speed, the time TR between consecutive frames can be chosen as: 100, 200, 400 or 800 ms. During the TR period the integration, readout and data transmission processes must occur. To save time, integration and transmission of the previous frame are overlapped. Because the maximum data value which can be transmitted during TRvalue, which can be transmitted during TR, is limited to 12288 bytes, it is not possible to read the total frame of 384x288 pixels, corresponding to 110592 bytes. We are forced to read only a sub-frame, or to reduce the number of pixels by summing them on chip. The combination of different scientific requirements, integration times and hardware limitations led us to the definition of 40 operation modes, which can be selected through commands sent to the spacecraft, ranging from the nominal (spatial x spectral) mode (128x96 with summation of 3x3 pixels), to the high spectral resolution mode (64x144 with summation of 3x2 pixels)., too the high speed mode (16x96) Summation along columns and rows will decrease the spatial and spectral resolution, but increases signal-to-noise ratio considerably. The implementation of mode 16x74 is the most critical due to the short time available to complete all the operations (TR = 100 ms). For this reason the Pattern Generator provides two values for the pixel readout frequency: f slow= 500 kHz when the pixel voltage has to be digitized and ffast = 4 MHz when the pixel is simply read from the CCD output register without any digital conversion.


SWIR Spectrograph

The IR channel is constituted of a telescope and its fore-optics, a beam splitter and two spectrometers, each with its detector array actively cooled.
 The telescope is a Cassegrain type one with a 200 mm focal length, a f/4 aperture, leading to a 1.2 mrad (4.1 arcmin) IFOV, and a 15 arcmin free field of view (including the positioning tolerances). The distance between the primary and the secondary mirrors is 51 mm; that between the secondary mirror and the image plane is 82 mm. In front of the telescope, a fore-optics system has the primary goal of providing a cross-track scanning of the IFOV.
 It includes two mirrors, a moving and a fixed one. The total scanning angle is +/- 4.4 degrees (FOV = 128 IFOV), and is adjusted to the OMEGA viewing direction. The control of the scanning mechanism is performed by a dedicated FPGA-based electronic sub-system.

Focused by the telescope on an entrance slit, through a shutter, the beam is first collimated, then separated, by a dichroic filter with its cut-off wavelength at 2.7 micrometresµm towards two spectrometers, operating in the following spectral ranges: 0.93 to 2.73 micrometersµm and 2.55 to 5.1 micrometersµm.
Each spectrometer includes a blazed grating working at its first order, and an optical reflective system, then a field mirror and a refractive refocusing system which gives a large aperture on the detection block (f/1.6): it images the spectrum onto a 128 elements InSb linear array, cooled down a temperature of < 80K, and multiplexed by a charge transfer device. Sets of filters are implemented in front of the detector to reject the contribution of other orders from the grating. The InSb photodiodes have been manufactured by SAT. The dimensions of each photosensitive element  iselement is 90 micron x 120 micronmicrons, with a pitch of 120 micron. All elements of the focal planes are hybridized on a ceramic with two electric circuit layers to connect the elements together. The ceramic is glued on a titanium base plate and covered with a titanium closure, which includes the filters. The output of each spectrograph is a series of 128 values each corresponding to a different wavelength. The SWIR unit provides 256 values at each acquisition. 

An internal calibration source is implemented, to control potential shifts of the overall spectrometer transmission, and to calibrate the relative response of each pixel. It is made of a tungsten lamp, operated as a black body which can be powerbody, which can be power, heated at different temperatures. The calibration beam is reflected towards the spectrometer by diffusion on the back sidebackside of the entrance slit.

SWIR requires an accurate thermal control, at three levels:

* - the IR detectors must be cooled down a temperature of < 80 K, controlled with an accuracy better than 0.1K. This is done by connecting them (copper heat link) to two cryocoolers, one for each array: they consist in Inframetrics 13000 series integral Stirling cycle coolers. Their guaranteed lifetimes are > 2500 hours. They are controlled by a dedicated electronics;
* - the spectrometer must be cooled down to 190 K, in order both to allow the detectors to reach their required operational temperature (< 80 K), and to minimize the thermal background. This is achieved by conductive coupling (heat pipes) to a “low temperature” radiator, provided by the S/C;
* - the electronics and the cryocoolers heads must be coupled (copper links) to a “high temperature” (280 K) radiator to dissipate their energy.

Contrarily to the VNIR spectrograph, which obtains a line of spectels, each with a complete VIS spectrum, at each acquisition, the SWIR spectrograph obtains a single spectrum at each acquisition. a SWIR line is constituted by a series of acquisitions during the forward motion of a scanning mirror (16, 32, 64 or 128 positions covering 1.1°, 2.2°, 4.4° or 8.8°), each acquisition providing 256 values at different wavelengths. 

The operating mode of the VNIR unit is constrained so as to be compatible with the NIR operating mode. The number of pixels in the line must be the same, so that the combined output of both spectrographs after a complete NIR scan is a series of 16, 32, 64 or 128 complete spectra, each with 352 spectels (nominal VIS mode) or 400 spectels (high spectral resolution VIS mode). 


OMEGA-ME Unit

The OMEGA main electronics is designed to power and control the instrument, to acquire and compress all scientific data on line, and to interface with the S/C telecommand/telemetry system. The entire system is cold redundant.
 Within OMEGA-ME, the Command and Data Processing Unit (CDPU) has the following tasks: 

* - acquisition of all scientific data from VNIR and SWIR;
* - formatting for real time data compression
* - wavelet based data compression, followed by formatting of processed data
* - reception and formatting of HK data
* - forward all data to the S/C telemetry system

The CDPU is based on a TSC21020 Temic processor, and integrated, together with a 6Mbyte SRAM, into a 3D packaged highly miniaturized cube, inherited from a ÇIVA/Rosetta development.


2.3 Data Handling Process


[Specify the institutes and names involved in the data preparation; give at least phone numbers and email addresses.
Indicate data levels as defined in the archive plan. 
Indicate software that is used to process the data]
Institut d’Astrophysique Spatiale is responsible for data preparation and distribution to CoI’s. The relevant contact information is provided in section ?1.71.7 page 45.n 1.9
    





Product Generation




The following table describes the OMEGA data processing level:

Processing Level
Definition
1A
Raw data that have been separated by instrument and sorted by orbit number. It contains science and housekeeping data.
1B	
PDS formatted data, including decompressed science data, housekeeping, and geometry data. The science data are still uncalibrated.
2
Calibrated science data resulting from the data reduction done by the OMEGA software provided the dataset.
3
High level derived product such as mineralogical maps

Table 1: Data Level Definition

IAS recovers two types of information relevant to OMEGA data:
* All packets with an OMEGA APID (pull from ESOC dds to IAS)
* SPICE kernels (pull from ESTEC navigation database to IAS).

They are automatically processed into OMEGA data products, using the following procedure.

1. Every 12 hours, the IAS gateway server checks the arrival of new OMEGA packets on the DDS server at ESOC. Science packets are sorted by orbit number (4 digits) by comparing the generation time of the packet and the sequence of apocenter times. The corresponding file, ORBNNNN.dds, constitutes the level-1A data product (archived at ESOC for six months and at IAS permanently). The HK packets are also sorted by orbit number, constituting a file HKNNNN.dds. If during such a search a new packet is found which belongs to an orbit with an already existing ORBNNNN.dds or HKNNNN.dds file, the file is reopened and the packet is inserted at the ranking corresponding to increasing APID’s. Only the last packet with a given APID is kept. If there is no file associated with the orbit of the packet, a corresponding ORBNNNN.dds is opened. At the end of the check procedure, all opened files are closed.

2. Once the checking procedure is complete, the server automatically reprocesses all level-1A data files, which have been created or modified. It sorts out the high rate telemetry packets, then decompresses the data and produces a series of preliminary PDS data cubes. Each data cube corresponds to the interval between the start and end of an observation (with a given set of observation parameters). There can be several observations for one orbit. The corresponding cubes are named ORBNNNN_0.QUB, ORBNNNN_1.QUB, …, ORBNNNN_9.QUB, then ORBNNNN_A.QUB, then B, C, and so on if there are more than 10 cubes for an orbit.

3. After all the relevant level-A files have been processed, the server processes each new preliminary cube by determining the geometric information relevant for each of the three channels, each scan and each pixel, and using the latest relevant kernel received from ESTEC. This generates an auxiliary geometry fileN, ORBNNNN_X.PRE. Part of the overall geometric information (e.g. minimum and maximum latitude, westernmost and easternmost longitude) is included in the label of the preliminary data cube, generating a final level-1B data cube ORBNNNN_X.QUB. The format of level-1B PDS files and associated auxiliary PDS files is given in section 5.2.

4. Every 24 hours, the kernel directory in ESTEC is checked. If a new kernel is available, it is retrieved by the server. All auxiliary geometry cubes with dates, which are covered by the new kernel, are then reprocessed so as to take into account this new positioning and/or pointing information. The corresponding level-1B data cubes are updated accordingly.

5. After 30 days, it is considered that the navigation information will not be updated for a given orbit. Every 24 hours, each auxiliary geometry cube for which the orbit is older than 30 days is copied into a geometry cube, ORBNNNN_X.NAV, which is therefore expected to provide the most accurate information on the observation geometry.

To each science level-1B PDS file is associated a geometry PDS file containing information on the projection of the looking directions on the surface of Mars. The format of level-1B PDS files and associated geometry PDS files is given in section ?4.14.14.3. The level-1B cubes will be used by the OMEGA team and they will be archived at the ESA’s Planetary Science Archive (PSA) for long term preservation.

During the proprietary period, a data reduction tool in IDL (readomega(lecomeg_1is made available to all coI’s to read the level-1B data set and to convert it data. A second series of processing tools (convomeg.pro, also in IDL) converts a level 1b data  set into a level 2a  data set (corrected for the photometric function, hence in physical units (W/m2/steradian/µm). This data set is relevant for regions of the spectrum dominated by thermal emission (typically above 4 µm). Another data set is provided in I/F, dividing by the solar spectrum, which is relevant for the region of the spectrum dominated by diffused sunlight (typically below 3 µm).isophotometric, spectral and geometric characteristics of the instrument). The level 2 data cubes, which are generated by convomeg.pro, will be in physical units (W/m2/steradian/µm) and will have theThese two data cubes have the  same dimensions as the corresponding level-1B cube. Eventually, The spectral information will be co-registered to the looking direction of the 65th spectel of the “IR C” channel of the OMEGA experiment.  Theseis second level of processing tools areis built on the best knowledge available on the instrument from ground calibration, self-consistency checks and comparison with other experiments (e.g. MOLA for altimetry data, THEMIS for spectral data). The OMEGA userteam is made aware that this understanding willmay  evolve with the learning curve on the actual behaviour of OMEGA around Mars. The signal/noise obtained by OMEGA can exceed 1000 over part of the wavelength range, not taking into account the along-track summing by a factor of 1 to 4 which can be performed on-board when 128 scans are implemented. No ground calibration can provide that level of confidence, in particular for visible-near IR imaging spectrometry. As an example, for this type of experiments, an absolute photometric calibration level of 10% is considered an ambitious goal, which can only be achieved after careful cross-comparison of actual data with the results of ground calibration and that of other experiments. Linearity or cross-talk at  aat a level of a few percent% has been observed to depend strongly on the stimulus during ground calibration.

 to reduce level 1b PDS cubes required by convomeg.proreduced data cubeslevel 2 data cubesthe first phases of  as ZIP files, with subdirectories (SOFTNN.ZIP providing the files necessary for version NN)A new version will be provided as a release when warranted by deeper level knowledge of instrument behaviour. SOFTNN.ZIP will unzip as a subdirectory (/SOFTNN) so as to maintain the history of the changes in the reduction process. It contains a readme file, SOFTNN_readme.txt, The file “softinfo.txt” will which s the changes since the last version (in particular in terms of photometric function and geometric calibration) and the confidence level, i.e. the magnitude of the variations in terms of spectral features which are considered reliable by the PI team. These are expected to improve until the end of the mission. the start of validity for each of the versions

The users are strongly advised to take into account the confidence levels in SOFTNN_readme.txt when publishing scientific results. A quality index will be defined so as to assess the confidence level in the reduction process. A processing tool (lecomeg_2) written in IDL will be made available so as to be able to read a level 2 OMEGA PDS cube. The auxiliary PDS file containing information on the looking directions on Mars will be the same than that for level 1, but only the “IR C” geometry information will be relevant. 

readomega.pro and its required input files,lecomeg_1, convomeg and lecomeg_2, A library written in C with the same capabilities will be provided in SOFTNN.ZIP so as to provide access to users which cannot use IDL due to funding limitations. 


1.1 The Planetary Data Center at IAS will also maintain an archive of the OMEGA products. Level-1B, geometry files and various software tools will be distributed to co-Is during the operational phase, Level 2 files will be maintained and distributed for several years, as data analysis progresses. Example dDerived products (level-3 files) will also be produced and distributed at IAS as examples of the science which can be done with OMEGA. They will also be provided to the archive when available in a PDS compliant format.. 



2.4 Overview of data products
 Overview of Data Products
1.1.1 [Explain all the data products that your team is going to deliver. The following subchapters will give you a roadmap what these products might be. In chapter 3, you have to deal with data sets and this chapter should be in preparation of the scheme how you distribute the different data products over the data sets. Accordingly, you might subsection the following sections.]
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
2.4.1 Pre-Flight Data Products


[Will your team deliver pre-flight data products, e.g. ground-based observations, campaigns with the instrument model on Earth, etc.
No ground calibration information will be made available. The OMEGA team will provide and update relevant information so that the processing pipeline is up to date with the current understanding of the characteristics of OMEGA. ]




2.4.2 Sub-System Tests


[Have you done any sub-system tests that might contribute to the understanding of the data? If yes, please specify and explain the tests. Refer to relevant documentation.]



The only relevant sub-system test for this purpose will be performed if an anomaly is observed in the data packets. A fixed test data set can be generated by a specific command so as to check the integrity of the downlink chain, in any of the possible observation modes of OMEGA. The processing pipeline will generate a level 1b1B file with a fixed data pattern whichpattern, which will have exactly the same format as a real observation with the same parameters.
2.4.3 Instrument Calibrations


Calibration files (at IAS and PSA)
* Spectral: Table giving for each channel (96 or144 visible, 256 IR) the exact spectral position 
* Geometric: Table giving for each pixel along a line (128 elements) the angular viewing direction
* Radiometric: Transfer functions for each of the three channels, covering (0.35-5.2 µm)


The current version of the photometric function, the wavelength scale and the solar spectrum at OMEGA wavelengths, are provided together with the OMEGA data reduction software.
Functional:
* 

2.4.4 Other Files written during Calibration

[Is there any other information available from calibration, e.g. database on used minerals and the result of other instruments using the same minerals?]
A series of observations of rocks and powders has been performed during calibration. These results have been is published:
G. Bonnello, J-P. Bibring, F. Poulet, A. Gendrin, B. Gondet, Y. Langevin, S. Fonti, S. (2004), Visible and infrared spectroscopy of minerals and mixtures with the OMEGA/Mars Express instrument. Planet. Space Sci. 52, p. 133-140
The corresponding spectradata set will in a numerical format can be made available through a direct collaboration with the authors.PI team. 




2.4.5 In-Flight Data Products

	
[Give a general overview of the data obtained during the active mission.
What are your data products? (cruise, mapping ,etc)
Please explain what these products describe,  
why did you selected them?
what processing level are they?
Can they be used for cross-instrument calibration?
Can they be used for cross-instrument scientific analysis?
Etc]

       Raw data (at ESOC, PSA and IAS)
ESOC and PSA will archive all data downlinked by MEX, sorted by APID
IAS will archive the packets relevant to OMEGA in dds format

Experiment Data Records (at IAS and PSA)
Level- 1b1B Science data product: ORBNNNN_X.QUBScience level 1b data product

One file, in PDS format, for each observationsession, including decompressed science data (level-1B), and all omega acquired HK.

Derived Data Records (at IAS and PSA)
Level-1B Geometry data product: ORBNNNN_X.NAV
One file, in PDS format, for each session, including all S/C derived geometrical information. A given file applies to a level-1B science data file and to the corresponding level-2 science data file


Reduced Data (at IAS, with selected subsets at PSA) and PSA?)
Level-32 Science data product
Example results when available.One file, in PDS format, for each session, including the science data in physical units (level 2)









2.4.6 Software
The data processing software of OMEGA is presently written in IDL. non-interactive modules in C will also be made available with the same functionalities, so as to provide access to scientists which do  not use IDL. It is also considered important  to have a backup strategy in case the long term availability of IDL is not guaranteed.calibration software:


2.4.6.1 Pipeline processing software

The MAKE_PDS tool is used to generate science level-1B data products. It will not be distributed neither at IAS nor PSA.

GEOMEG is an IDL library designed to generate the OMEGA geometry data products. This software will be archived at PSA. The tool is a SPICE-based software using the MEX kernels data set as ancillary data (see ?2.4.82.4.92.3.9 for details), and the MGS MOLA Mission Experiment Gridded Data Records as global topographic maps. The main GEOMEG functionalities are:
* searching/loading required kernels
* computing geometry information at times of pixels signal acquisition
* formatting data in PDS format
* updating science data product label

2.4.6.2 Data reduction software

The archive will include the software tools to reduce level 1B PDS cubes, but not the reduced data cubes, as these may evolve rapidly during the mission. The software tools will be included in the SOFTWARE directory as ZIP files indicating the version number. A new version will be provided as a release when warranted by deeper level knowledge of instrument behaviour. It contains a readme file, which indicates the changes since the last version (in particular in terms of photometric function and geometric calibration) and the confidence level, i.e. the magnitude of the variations in terms of spectral features, which are considered reliable by the PI team. These are expected to improve until the end of the mission.

After the proprietary period, the same information (level-1B and processing tool to level-2) will be made available to the wide scientific community. The wide scientific community will be made aware that this “best-effort” level-2 processing tools may be superseded by later versions as the understanding of the instrument behaviour around Mars continues to improve. The users are strongly advised to take into account the confidence levels in the readme file encoded in the software package when publishing scientific results. The basic software tools (and its required input files, all in IDL) will be archived as part of the data volumes provided by IAS. A library written in C with the same capabilities will be provided in the software package so as to provide access to users, which cannot use IDL due to funding limitations. The main tools for using OMEGA data are described in the document: 
  softNN_readme.txt   
encoded in the SOFTNN.ZIP file SOFTWARE directory.  A path file (omega_path), included in SOFTNN.ZIP needs to be edited to the specific user environment so as to provide the proper path to the OMEGA data directory, where the user stores the data cubes (ORBNNNN.QUB) and the OMEGA geometry directory, where the user stores the geometry cubes (ORBNNNN.NAV).  The  readomega.pro routine reads an omega data cube, creating IDL arrays idat (raw data), jdat (I/F) and kdat (radiance). Readomega also reads the companion geometry cube, providing information on the location of the IFOV of each pixel on Mars (or Phobos, when relevant) as derived from the SPICE kernels provided by the project. Input files to readomega.pro are also included in SOFTNN.ZIP, providing the current version of the photometric function, the wavelength scale and the solar spectrum at OMEGA wavelengths which is used to derive I/F values from radiance values.
See document [n/a] for further information.


scientific analysis software:
ENVI, etc …







2.4.7 Documentation


The main document provided in the DOCUMENT subdirectory is the EAICD itself, which contains all the relevant information on the content of the ORBNNNN_S.QUB level- 1b1B science PDS cube and the corresponding geometryic cube ORBNNNN_S.NAV. The OMEGA Flight User Manual will also be provided as WORD and PDF document. This document will be provided both as a pdf file and as an ASCII file, with the figures in png format (EAICD_Fig1.PNG, EAICD_Fig2.PNG …). Additional information is provided as small ASCII text file pointed by the data product label. Please refer to the section ?3.4.53.4.5 page 1820 describing the DOCUMENT directory content.by  INSTRUMENT.CAT (CAT directory), OMEGA_DESC.TXT,  OMEGA_CALIBRATION_DESC.TXT and GEOCUBE_DESC.TXT (DOCUMENT directory)
  what documentation you will provide in the doc directory
* what documentation you will provide in the extras directory
* what format you will use
* how do you handle images and drawings in ASCII file, that are normally bundled in your documents? (e.g. will you create PNG files for each image in a WORD document?)

    
    
    

1.1.1 Derived and other Data Products
      
[Will you provide any other derived data (even outside of the official archiving efforts)?
Will you provide data products that result from co-operation with other instrument teams?]


All derived data (level-3) will be distributed in PDS format at IAS when ready, including:

* Spectral cubes providing radiance spectra of the whole surface, derived from data merging of low-resolution observations. The tiling scheme is TBD, but will be as consistent as possible with other experiment products (TES…).
* Cubes of modelled surface spectra, consisting in data spectrally merged with first order correction for thermal emission, atmospheric absorption and scattering, and surface photometric effects. These spectra will provide an estimate of surface normal albedo between 0.35 and 5.2 µm.
* Spectral units maps, as derived from data analysis, together with corresponding type spectra. 
* Mineralogical maps deriving from data analyses. These maps will represent mineralogical fractions and estimated grain size in the observed regions.
* Seasonal maps (clouds, dust storms, etc…).

* Data derived from limb observations (gas and dust profiles, etc…).



Representative level-3 products (maps) will be delivered to ESA for public outreach purpose.
     
2.4.8 Ancillary Data Usage

As mentioned in section ?2.4.62.4.62.3.6, we use SPICE kernels to generate the geometry data products. SPICE kernels are ancillary data files, which hold all the relevant information required to produce OMEGA observation geometry calculation. MEX-specific kernels are either converted from ESOC auxiliary data: orbit attitude, and time correlation files, or designed by the NAIF team. The following table described the kernels used by GEOMEG. This software also uses global topographic maps of Mars provided by the MOLA Mission Experiment Gridded Data Records (MEGDRs) at resolutions of 64, and 128 pixels per degree. See http://pds-geosciences.wustl.edu/missions/mgs/megdr.html for further details.





Type
Name
Description
SPK
ORMM__YYMMDDhhmmss_xxxxx.BSP*
This file contains a Mars Express predict ephemeris after orbit insertion covering the time span starting at the date YYMMDDhhmmss.
CK
ATNM_PYYMMDDhhmmss_xxxxx.BC*
Contains Mars Express predicted attitude information covering the time span starting at the date YYMMDDhhmmss
SCLK
MEX_yymmdd_STEP.TSC
This file is a SPICE spacecraft clock (SCLK) kernel containing information required for MEX spacecraft on-board clock to UTC conversion. This file provides the same time information that the Time Correlation packets released via DDS.
FK
MEX_Vxx.TF*
File containing the complete set of frame definitions for the Mars Express Spacecraft (MEX) including definitions for the MEX science instrument frames. This kernel also contains NAIF ID/name mapping for the MEX instruments.
IK
MEX_OMEGA_Vxx.TI*
File containing OMEGA detectors geometry: scanning mirror motion, pixel field of view and optical distortion parameters
SPK
DE405S.BSP
Contains ephemeris data for planet barycenters, and for the sun, earth and moon mass centers. Spans the entire MEX mission.
SPK
MAR033_2000-2025.BSP
Contains ephemeris data for Phobos and Deimos. Spans the entire MEX mission.
LSK
NAIF0007.TLS
File specifying the relationship between the Barycentric Dynamical Time (TDB, also called ephemeris time) and Coordinated Universal Time (UTC) up to the last modification in the leapseconds: December 31, 1998.
PCK
MARS_IAU2000_V0.TPC
File containing the radii and orientation constants for Mars and its natural satellites.
*‘x’ tokens indicate the version number of the kernel file.

       Table 2: SPICE kernels used in Data Processing



[list state here the involved teams, physical locations, names with responsibilities, are involved to process the data. 
1 Indicate data levels as defined in the archive plan. 
1 Indicate software that is used to process the data ]
3 Archive Format and Content
1.1  [This chapter contains general rules and constrains for your data sets. The scheme or convention you will use for naming your directories and file names shall be specifiec below. It might be, that the information given here is short in nature or in some cases not available. Simple keep it short or write “n/a”, if applicable.
1.1 Specific and detailed information will go into a subchapter of chapter 4.3, 'Data Product A Design' etc][this chapter contains general rules and constrains for your data sets. The scheme or convention you will use for naming your directories and file names shall be specifiec below. It might be, that the information given here is short in nature or in some cases not available. Simple keep it short or write “n/a”, if applicable.
1.1 Specific and detailed information will go into a subchapter of chapter 4.3, 'Data Product A Design' etc]
1.1 
1.1 
1.1 
1.1 
1.1 
1.1 
1.1 
3.1 3.1 Format and Conventions
1.1.1 [this chapter contains general rules and constrains for your data sets. Specific and detailed information will go into chapter 'Detector A' etc]
3.1.1 3.1.1 Deliveries and Archive Volume Format	

The OMEGA data is delivered according to the “release” procedure, i.e. there is a single data set and data volume. A new release is provided for each complete set of 100 orbits. The name of the data volume is:
 OMEGA-FR-CNES-CNRS-MEXOMG-0001


1.1.1  The OMEGA data volumes are named according to the set of 100 successive orbits, which correspond to data acquisition. Example: ORB12 corresponds to orbits between 1200 and 1299. The full name of the volume is therefore:
1.1.1 
1.1.1 FR-CNRS-PLANET-ME-EDR-ORBNN
1.1.1 
1.1.1 Isn’t there only ONE archive volume? (release concept)
1.1.1 [ESA/PSA aims to electronic data delivery only. Experiment teams shall deliver only LOGICAL ARCHIVE VOLUMES. This can be compared to having one data set per archive volume. The size of a logical archive volume shall be the volume of a CD (<650 Mbytes) or if not feasible the size of a DVD (4.73.9Gbytes). The logical archive volume is an entity that can be distributed to the scientific community. For long-term archive purposes and dedicated scientific requests the PSA will generate and create physical archive volumes (as you know them from the past) on the fly on a physical media that might change over time. 
1.1.1 Explain your volume naming scheme.]. 
1.1.1 [NASA/PDS aims for deliveries of archive volumes on physical media, … [to be filled in by PDS]]
3.1.2 3.1.2 Data Set ID Formation Naming Conventio

[Explain your data set id naming[ explain your data set id naming]]
      
      
      The OMEGA data set ID is formed according to the scheme:<

mMission>-< –target>- <eExperiment – Target >-– <llevel>- <– ttype>-<name>-<version>:  
MEX-M-OMEGA-2-EDR-0000-0010-V1.0MEX-M-OMEGA-2-EDR-FLIGHT-V1.0
mission-target-experiment-level-200402200404
MEX-M-OMEGA-2-YYYYMM-YYYYNN-V1.0

Isn’t there only ONE data set? (release concept)
3.1.3 3.1.3 Data Set  Directory Naming ConventionStructure
nt

The following figure shows the OMEGA data set directory structure:





ORBNN: pds data cubes from orbit NN00 to orbit NN99
GEMNN: pds geometry cubes from orbit NN00 to orbit NN99this is redondant with section  …
[
 explain your naming convention that you will use below the /data directory.data ]
1.1.1 
1.1.1 set naming]
1.1.1 
1.1.1 
1.1.1 3.1.43 Filenaming Convention 

 in HEX format (0 to 9, then A to F)., starting from 0 to 9 then from A to Z Each pair of QUB and NAV files, corresponds to indicating data  same obtained by OMEGA  with the sameof













 Figure 1: Data Set Directory Structure
3.1.4 File Naming Convention

The following table describes the naming convention used for files within the data directory:

Data product
Level
File name
Science data
1B
ORBnnnn_x.QUB

1B
CRUISEyymmdd_x.QUB
Geometry data
1B
ORBnnnn_x.NAV
where ‘nnnn’ is a four-digit number representing the orbit number at the observation time, where ‘x’ is a one-digit character in HEX format (0 to 9, then A to F), and ‘yymmdd’ represents the time of observation during the cruise phase. Each pair of QUB and NAV files corresponds to a data set obtained by OMEGA  with the same observation parameters.

Table 3: File Naming Convention
1.1 [explain rules to generate your products. ONE convetionne general rule shall be designed for all data products throughout the mission.
1.1 E.g. 
1.1     <inst>_<detector>_<datatype>_<begin of observation>_<length of observation>_<inst mode>.<ext>
1.1 Please use the available 27.3 characters that are available for you. Your filename shall be uniquely defined, such that downloading a file alone, the user has a rather good idea what data products he has in his hands.]
3.2 3.2 Standards Used in Data Product Generation
[describe the standards used; this might be easy and straightforward, but a mistake will be very expensive to correct during the active mission]
[Describe the standards used; this might be easy and straightforward, but a mistake will be very expensive to correct during the active mission.



3.2.1 3.2.1 PDS Standards

The PDS standard for the cubes is that of PDS version 3.6 as described in the document ?[2][2] (JPL D-7669 part 2)
3.2.2 Time Standards

ThreethreeFour time standards are used in the OMEGA data products:
* UT: year, month, day, hour, minute, second, millisecond
* SCET: seconds and fractions of seconds since January 1st 1970, 00:00:00
* On-Board time: seconds and fractions of seconds since last switch-on of the spacecraft (nominally after launch)

The On-Board time is the only time available to the instrument during operation. It is reset each time a “time” TC is received by OMEGA. OMEGA uses a timer to update this time between two successive timetimes TC. The on-board time  attime at generation is written by OMEGA within each generated data packet

For each packet, The SCET is generated by the spacecraft from the on-board time in the packet, according to its time synchronization information

The UT time is generated by the DDS ground segment system from the SCET time when it encapsulates the packets so as to generate level 1a level-1A files
* MIRA: minutes and fractions of minutes with reference to the pericenter of the current orbit

MIRA?
3.2.3 Reference SystemsCartographic Standards

Inertial Reference frame – The Earth Mean Equator and Equinox of Julian Date 2451545.0 (referred to as the J2000 system) is standard inertial frame.

Mars Body-Fixed Frame – Body fixed frames are reference frames that do not move with respect to surface features of an object. The Mars Body-Fixed frame center is the center of mass of Mars. The spin axis of Mars defines the z-axis, whereas the prime meridian provides the direction of the x-axis that lies on the equatorial plane. The y-axis completes the right-handed frame. Values used to model the orientation of the north pole (including precession), and the prime meridian as a function of time, are those recommended by the International Astronomical Union and adopted by the Mars Express project.

Coordinates System – We use the planetocentric coordinates system that consists of longitude measured positive eastward and planetocentric latitude, defined as the angle between the equatorial plane and a line from the center of mass of Mars to given point. This system is right-handed and identical to spherical polar coordinates as commonly defined. Longitudes range from 0 to 360 degrees, and latitudes range from –90 to 90 degrees. Please refer to document ?[5][5] for further information on IAU 2000 standards.

Reference Surface – Two standards are used to model the surface of Mars. The first one is the digital terrain model (DTM) based on MOLA data, which defines Mars radius as a function of planetocentric latitude and longitude in the Mars-Body fixed frame. The second one is the triaxial ellipsoid centered on the planetocentric system origin that fits at best the MOLA data. Note that the reference ellipsoid is used only the reference surface for defining map projections, whereas detailed topographic model (DTM) is used for accurate projection of remote-sensed data.

Open issues – Cartographic constants used for OMEGA data mapping can be found in the document ?[5][5]. Data acquired on Phobos will use Simonelli’s model (TBC with T. Duxbury and ESA). OMEGA cartographic products will use a simple cylindrical projection, and possibly polar projections for regions located above 60° in latitude (TBC), so as to facilitate changes in data projections and comparison with other data sets.

3.2.4 Other Applicable Standards

n/a
3.2.2 Time Standards
3.3.3 ReferenceCoordinate Systems

          
3.3.4 Other Applicable Standards


1.1 
3.3 3.3 Data Validation
 	


The individual packet validation is performed by ESOC, which rejects non-compliant packets. All valid OMEGA packets containing science data (type 20, subtype 13) are integrated into the level-1A files to be processed into a set of PDS level-1B data products.

OMEGA data is structured into sub-slices of 64 pixels by 64 spectels (48 spectels for the VIS channel in the nominal mode, 64 spectels or 80 spectels for the visible channel in the high spectral resolution mode), each corresponding to an integer number of packets (1 in most compression modes, 2 for non compressed formats). A consistency check is performed during the decompression of the data stream. If the number of words required for decompression is different from the number of available data words, one considers that a SEU has occurred and the corresponding sub-slice values are set to 0. 

The OMEGA team members validate conversion of level-1B products into level-2 products interactively during the proprietary period. At the end of the proprietary period, a set of software products will be released, so as to provide the tools to generate level 2 level-2 products from the level 1b1B products in the database. It is expected that the understanding of the instrument behaviour will improve during the next few years, as was the case for other experiments of this type. These software products will be therefore be updated whenever a new release is deemed necessary first set of level 2 products is generated at the end of the proprietary period.. Similarly, the calibration data may be updated if the characteristics of the instrument in terms of spectral, spatial or radiometric performances change with time.  A quality index will be defined so as to warn the general user on the possible scope of further updates based on an improved understanding of the in-flight characteristics of OMEGA.

The datasets will be validated through the PVV tool, and a peer review. 
The main purpose of PVV, distributed by ESA, is to provide the instrument archive team with a tool that allows it to check and verify their datasets before sending them to the PSA. It also shall be taken into account that this same tool will be used in the PSA before ingestion as an additional security step, to prevent whomever from accidentally or intentionally ingesting a wrong or corrupted dataset. It might happen too that some part of the dataset is lost during the transmission process, so the tool should prevent somehow for this inconvenience.
1.1 [Describe validation procedures applied to data products to ensure that their contents and format are free of errors. This may be a brief overview, if the details are described in another document]
3.4 Data Set Directories 3.4 Content
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 [ this subchapter shall contain allALL the information that is data productetector independent but is usually the same for all (most) data sets.]defines the deliverables to the PSA]
1.1.1 3.4.1 Volume Set
1.1.1 
1.1.1 
1.1.1 
1.1.1 [ESA/PSA: please detail what kind of data will be distributed in which volume set, remember we plan for electronic delivery and there is no real need to bundle several dat a sets into one volume set; there for as a general rule, a volume shall be a dataset]
1.1.1 [NASA/PDS: to be filled in by PDS]
1.1.1 3.4.2 Data Set
1.1.1 
1.1.1 
1.1.1 
1.1.1 3.4.3 Directories
1.1.1 [create table that shows data set id name, expected delivery, size, data types contained, etc
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 [ in the following subsubchapters, please describe (make a few diagrams) of how your directory structure is setup.
1.1.1 Explain what the purpose of each directory is and what kind of information you will give there. If it is necessary to do this for each detector of your instrument: do it. Your data shall be in a directory named 'data' followed by the name of either your instrument or your detector, e.g. The data for instrument xy shall be on directory 'data/xy/*'
1.1.1 For most of the catalog files there are templates available, ask your archive contact at ESTEC 
1.1.1 it may be necessary, to create several tables, e.g. One for each mission phase]]
1.1.1 If a directory of file does not make sense for your data sets, please leave the chapter in this document, and write 'n/a']]
3.4.1 3.4.3.1 Root Directory

Files in the Root Directory include an overview of the archive, a description of the volume for the PDS Catalog, and a list of errata or comments about the archive. The following files are contained in the Root Directory.

File Name
File Contents 
AAREADME.TXT
Volume content and format information 
ERRATA.TXT
A cumulative listing of comments and updates concerning all archive volumes published to date
VOLDESC.CAT
A description of the contents of this volume in a PDS format readable by both humans and computers


1.1.1.1 3.4.3.2 Calibration Directory

The Calib Directory contains calibration files used to process the data products, and calibration data needed to use the data products. The following files are contained in the Calib Directory.

File Name
File Contents 
CALINFO.TXT
A description of the contents of this directory








1.1.1 
3.4.2 3.4.3.3 Catalog Directory

The files in the Catalog Directory provide a top-level understanding of the mission, spacecraft, instruments, and data sets. The files in this directory are coordinated with the PSA team, who is responsible for loading them into the PDS catalog. The following files are found in the Catalog Directory.

File Name
File Contents 
CATINFO.TXT
A description of the contents of this directory
DATASET.CAT
Data set information for the PDS catalog
INSTHOST.CAT
Instrument host (spacecraft) information for the PDS catalog
INST.CAT
Instrument information for the PDS catalog
MISSION.CAT
Mission information for the PDS catalog 
SOFTWARE.CAT
Software information for the PDS catalog
RELEASE.CAT
For each data set, there is one release catalog file which defines, through release objects, a data products delivery to the PSA

1.1.1               3.4.3.3.1 Mission Catalog File 	[to be copied from ESA]
1.1.1 3.4.3.3.2 Mission Host Catalog File 	[to be copied from ESA]
1.1.1 3.4.3.3.3 Host Instrument Catalog File
1.1.1 3.4.3.3.4 Instrument Catalog File
1.1.1 3.4.3.3.5 Personnel Catalog File
1.1.1 3.4.3.3.6 Reference Catalog File
1.1.1 3.4.3.3.7 Dataset Catalog File
1.1.1 3.4.3.3.8 Map Projections Catalog File
1.1.1 3.4.3.3.9 Targets Catalog File
3.4.3 3.4.3.4 Index Directory

Files in the Index Directory are provided to help the user locate products on this archive volume and on previously released volumes in the archive. The following files are contained in the Index Directory.


File Name
File Contents 
INDXINFO.TXT
A description of the contents of this directory
INDEX.TAB
A table listing all data products on this volume 
INDEX.LBL
A PDS detached label that describes INDEX.TAB
GEO_MARS.LBL
Geometry Index label for GEO_MARS.TAB
GEO_MARS.TAB
Geometry Index Table providing geometry and position information about the data product listed in INDEX.TAB
OMEGA_INDEX.LBL
Index Label for OMEGA_INDEX.TAB
OMEGA_INDEX.TAB
Additional Index Table providing information about OMEGA at the time of observation, plus other geometrical parameters

Please refer to document ?[6][6] for further information on geometry index, and refer to index label files themselves to have a complete description of the index table parameters.
Open questions: 

- Data quality flag in index file?
- Release index file (INDEX_ORBnn_mm.TAB, where ‘mm’ would be the revision number)?


	



[ESA/PSA: the basic assumption for this subchapter is that information 
* likely to be updated shall be stored in index files. 
* Likely to be used in database designs shall be stored in index files.
* Not clearly known during the design phase (e.g. cross-instrument information, environmental conditions)
An example is the information on FOV (field of view) of an imaging instrument. The information may also go  into a data product label. If however after the official data delivery an update is required, only the index files will be updated.]
1.1.1.1.1 3.4.3.4.1 Dataset Index File, index.lbl and index.tab
1.1.1.1.1 3.4.3.4.2 Geometric Index File, geoindex.lbl and geoindex.tab
1.1.1.1.1 3.4.3.4.3 Oother Index Files
1.1.1.1 3.4.3.5 Browse Directory and Browse Files
1.1.1.1 3.4.3.5  Geometry Directory

The Geometry Directory contains files needed to understand observation geometry. The following files are contained in the Geometry Directory.

File Name
File Contents 
GEOMINFO.TXT
A description of the contents of this directory








1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 Open questions:
1.1.1 - Do we intend to archive SPICE kernels required to generate geometry data products, or just point to them from a separate index or document?
1.1.1 - Same question about the MOLA data set?
3.4.4 3.4.3.6 SSoftware Directory

The Software directory contains software for extracting data from the data product files, and for data reduction. The main tools for using OMEGA data are described in the document: softNN_readme.txt encoded in the SOFTNN.ZIP file. It will unzip as a subdirectory (/SOFTNN) so as to maintain the history of the changes in the reduction process. A path file (omega_path), included in SOFTNN.ZIP needs to be edited to the specific user environment so as to provide the proper path to the OMEGA data directory, where the user stores the science data cubes and the OMEGA geometry directory, where the user stores the geometry cubes The readomega.pro routine reads an omega data cube, creating IDL arrays idat (raw data) ), jdat (I/F) and jkdat (radiance). The readomega tool also reads the companion geometry cube, providing information on the location of the IFOV of each pixel on Mars (or Phobos, when relevant) as derived from the SPICE kernels provided by the project. Input files to readomega.pro are also included in SOFTNN.ZIP, providing the current version of the photometric function, the wavelength scale and the solar spectrum at OMEGA wavelengths, which is scaled to the current heliocentric distance by readomega (specmars). specmars, which canis be used to derive I/F values from radiance values. The user can consider using other versions of the solar spectrum, but he should be aware that the photometric calibration has been fine-tuned so as to be compatible with the solar spectrum as provided.

The following files are contained in the Software Directory:
[subdirectories shall be named in such a way that it is easy to understand what kind of software, what release and for which operating system it is intended; if the content of this directory was distributed identically on a previous data set, you can point to the former data set. How to point to the former data set needs to be defined

File Name
File Contents 
SOFTINFO.TXT
A description of the contents of this directory
SOFT01.ZIPLECOMEG.PRO
A ZIP file withcontaining all needed files for OMEGA data  reduction f
For the first release (first public delivery)
SOFT01.LBLGEOMEG_RGEOLBL.PRO
The label for this file
ZIPINFO.TXTSOFT02.LBL
This file provides an overview of the ZIP file format The label for this file
SOFT02.ZIP........
A ZIP file with the second version of the OMEGA reduction
SOFT02.LBL
The label for this file
…
…








[this directory contains software for data calibration and for data visualisation; subdirectories shall be named in such a way that it is easy to understand what kind of software, what release and for which operating system it is intended; if the content of this directory was distributed identically on a previous data set, you can point to the former data set. How to point to the former data set needs to be defined.]
1.1.1 3.4.3.7 Gazetter Directory
1.1.1 
1.1.1 [The files in this directory shall contain information in textual and tabular format about named features of the observation site. The information given here is NOT approved by the International Astronomical Union, it is given as a convenience for the researchers in the future]
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 [the files in this directory shall contain information in textual and tabular format about named features of the observation site. The information given here is NOT approved by the International Astronomical Union, it is given as a convenience for the researchers in the future]
1.1.1 3.4.3.8 Label Directory
1.1.1 
1.1.1 [The label directory contains include files referenced by data files on this volume, e.g. FMT files containing label definitions used in data label files]
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 	[contains include files referenced by data files on this volume, e.g. FMT files containing label definitions used in data label files]
3.4.5 3.4.3.9 Document Directory

The Document Directory contains documentation to help the user understand and use the archive data. The following files are contained in the Document Directory.

File Name
File Contents 
DOCINFO.TXT
A description of the contents of this directory
EAICD_OMEGA.DOC
The OMEGA Experiment Archive Interface Control Document (this document) as a WORD document
EAICD_OMEGA.ASC
The OMEGA Experiment Archive Interface Control Document (this document) as text.
EAICD_OMEGA.PDF
The OMEGA Experiment Archive Interface Control Document (this document) as a PDF file.
EAICD_OMEGA.LBL
A PDS detached label describing all EAICD related documents and figures.PDFTXT,  andTXT and its PNG figuresPDF
OMEAICD_FIG1.PNG
PNG Figure 1 for the ASCII version
OMEAICD_FIG2.PNG
PNG Figure 2 for the ASCII version
EAICD_FIG3.PNG
PNG Figure 3 for the ASCII version
EAICD_FIG4.PNG
PNG Figure 4 for the ASCII version
EAICD_FIG5.PNG
PNG Figure 5 for the ASCII version
OMEGA_FUM.DOC
The OMEGA Flight User Manual as WORD document
OMEGA_FUM.PDF
The OMEGA Flight User Manual as PDF document
OMEGA_FUM.LBL
A PDS detached label describing FUM related documents
GEOCUBE_DESC.TXT
Description of the geometry data cubes content
MEX_ORIENTATION_DESC.TXT
Description of the Mars Express spacecraft orientation
OMEGA_CALIBRATION_DESC.TXT
Description of the OMEGA calibration parameters
OMEGA_DESC.TXT…………………….
Description of the OMEGA instrument
GEOCUBE_DESC.LBL
Label file for GEOCUBE_DESC.TXT
MEX_ORIENTATION_DESC.LBL
Label file for MEX_ORIENTATION_DESC.TXT
OMEGA_CALIBRATION_DESC.LBL
Label file for OMEGA_CALIBRATION_DESC.TXT
OMEGA_DESC.LBL
Label file for OMEGA_DESC.TXT

1.1.1 Open questions:
1.1.1 - How do you handle images and tables when reformatting e.g. from WORD into ASCII?
1.1.1 - What documents will not go here but will go to the EXTRAs directory?
1.1.1 
1.1.1 - What about the calibration and geometry documentation?
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 [ list the documents that will fill this directory. How do you handle images and tables when reformatting e.g. from WORD into ASCII? What documents will not go here but will go to the EXTRAs directory? The EAICD shall be on the document directory.] 
1.1.1 3.4.3.10 Extras Directory
1.1.1 
1.1.1 [The EXTRAS directory gives you the possibility to add value to your data set. Please provide additional documentation, html or xml pages that describe your data set, pictures and figures, etc]
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 
1.1.1 [The EXTRAS directory gives you the possibility to add value to your data set. Please provide additional documentation, html or xml pages that describe your data set, pictures and figures, etc]
3.4.6 3.4.3.11 Data Directory

The Data directory contains the science and geometry data product, both at level-1B. Science data files are sorted into subdirectories by groups of 100 orbits according to the following scheme:

       DATA
  |
  `- ORBnn

where ‘nn’ are the first two digits of the stating orbit number. Data obtained before arrival at Mars (EV and IC mission phases) are stored in the CRUISE sub-directory according to the following scheme:

DATA
  |
          `-- CRUISE

Geometry data files are sorted into subdirectories by groups of 100 orbits according to a similar scheme:

DATA
  |
  `-- GEMnn

where ‘nn’ are the first two digits of the stating orbit number. Example: the ORB12 subdirectory contains all the data files corresponding to orbits from 1200 and 1299. There are no geometry data products for cruise data.

Science and geometry data files are named according to the Table 3 page 1416.
1 

1 
1 
1 
1 
1 
1 
1 [ the directories below the data/ /data directory shall be named after e.g. the detectors and the processing level, e.g. detectorA_1b for raw data or detectorA_2 for higher level data. If there are directories below this level, they shall be named after a logical structure, e.g. Mission phase names or orbit numbers etc shall be used. Explain the scheme or rule of your data directory design.]
1 
1 3.4.4 Data and Label Files
1 		[explain how you handle label and data files, especially give information on 
1 usage of attached or deteached labels
1 usage of pointers
1 usage of fmt files
1 usage of quicklook files
1 etc]
1 3.4.45 Pre-Flight Data Products
1 	[	will your team deliver pre-flight data products, e.g. ground-based observations, campaigns with the instrument model on Earth, etc.]
1 3.4.56 Sub-System Tests
1 	[	have you done any sub-system tests that might contribute to the understanding of the data? If yes, please specify and explain  the tests. Refer to relevant documentation.]
1 3.4.67 Instrument Calibrations
1 	[
1 is there any instrument calibration information available,
1  any data, 
1 reference documents, 
1 will you put the documents in the extras directory?
1 ]
1 3.4.78 Other Files written during Calibration
1 [Will you archive calibration data? If yes, which ones? Explain.]
1 
1 3.4.89 In-Flight Data Products
1 	[
1 What are your data products? 
1 Please explain what these products describe,  
1 why did you selected them?
1 what processing level are they?
1 Can they be used for cross-instrument calibration?
1 Can they be used for cross-instrument scientific analysis?
1 Etc
1 ]
1 3.4.010 Software
1 [give a short overview on
1 calibration software
1 pipeline processing software
1 scientific analysis software
1 ]
1 3.4.101 Documentation
1 [give a short overview  on
1 what documentation you will provide in the doc directory
1 what documentation you will provide in the extras directory
1 what format you will use
1 how do you handle images and drawings in ASCII file, that are normally bundled in your documents? (e.g. will you create PNG files for each image in a WORD document?)
1 ]
1 
1 3.4.113 Derived and other Data Products
1 
1 
1 [
1 will you provide any other derived data (even outside of the official archiving efforts)?
1 Will you provide data products that result from co-operation with other instrument teams?
1 ]
1 
4 4. Detailed Interface Specifications
1.1 	[ In the previous chapter rules or conventions where given. Iin this chapter, detailed information on the dataset, directory and filenaming,  of your about the archive design at instrument and detector/sensor level is given. ]
1.1  
1.1 [In the previous chapter rules or conventions where given. In this chapter, detailed information on the dataset, directory and file naming, of your archive design at instrument and detector/sensor level is given.]
1.1 
1.1 
1.1 
1.1 
1.1 4.1 Structure and Organization Overview
1.1 	[Ggive detailed overview of the /data is detectors directory structure organization, file naming scheme used in detail.]
1.1 
1.1 [Give detailed overview of the /data directory structure organization, file naming scheme used in detail.]
1.1 
1.1 
1.1 
1.1 
1.1 
1.1 4.23 Data Sets, Definition and Content
1.1 
1.1 [Details of the data sets to be generated. File naming of the data sets, contents of the datasets. Table with delivery dates and delivery volume and data type, etc]
1.1 	[details of the data sets to be generated. File naming of the data sets, contents of the datasets. Table with delivery dates and delivery volume and data type, etc]
1.1 
1.1 
1.1 4.4 Data Product Identification
1.1 [is your data product equal to a data file? Remember, it may be that you have one data product, but several data files]
1.1 4.5 PDS Label Structure, Definition and Format
1.1 [describe what kind of non-instrument related information you give in the labels. Do you use mission specific keywords? ]
4.1 4.36 Overview of DetectorsData Product Design






	[ for each of your different data products, give the details of the label files in one subchapter. You	may define a data product:
* For each sensor, for each data product level
* For each combined and derived data product
* For each model based data product
[is your data product equal to a data file? Remember, it may be that you have one data product, but several data files]
A series of PDS files starting from level-1B is generated for each sub-session of OMEGA, i.e. a series of scans performed in the same operational mode (IR mode, VIS mode, spatial summing) as described in ?2.22.2. These PDS files contain all the scientific data and geometry data produced by OMEGA. The PDS label is always included in the file
4.1.1 4.36.1 Data Product A DesigSciencen Level-1B Data Product

[Details of the content of this data product label, line by line. For each instrument and detector related keyword defining an enumeration type (fixed amount of values) give a list of the foreseen values. For non-enumeration types give a typical value for the keyword.
You may define the labels in a label file and include this file here.]Detector A data level X





The EDR data files (ORBNNNN_M.QUB) contain the DN numbers from the experiment as PDS files in the QUBE format. An example PDS label for a 1B OMEGA data PDS file is given in annex BA. 

4.1.1.1 File Characteristics Data Elements

PDS data product labels contain data element information that describes important attributes of the physical structure of a data product file. The PDS file characteristic data elements are:

RECORD_TYPE
RECORD_BYTES
FILE_RECORDS
LABEL_RECORDS
FILE_NAME

The RECORD_TYPE data element identifies the record characteristics of the data product file. Physical records are always fixed-length. The RECORD_BYTES data element identifies the number of bytes in each physical record in the data product file. Records length is always equal to 512 bytes. The FILE_RECORDS data element identifies the number of physical records in the file. The LABEL_RECORDS data element identifies the number of physical records that make up the PDS product label. The FILE_NAME data element identifies the name of the geometry file. 

The Planetary Science Archive of ESA implements the “Release” concept: data is delivered as units (releases), which can be updated (revision). Two specific data elements are included to handle the release concept: 

       RELEASE_ID
       REVISION_ID
	
     	RELEASE_ID defines the release number and REVISION_ID defines the revision number.

4.1.1.2 Data Object Pointers Identification Data Elements
 
The label refers to a single data object, which is a QUBE.  The data object starts in the next physical record after the PDS product label area. The data object pointer takes the following form:

^QUBE = nnn

where nnn represents the starting record number within the geometry file (first record is numbered 1).

4.1.1.3 Data Identification Elements

The following data identification elements provide additional information about the data product.

DATA_SET_ID                    = "MEX-M-OMEGA-2-EDR-FLIGHT-V1.0""MEX-M-OMEGA-2-EDR-0000-0010-V1.0"
PRODUCT_ID                     = "ORB0018_1_DATA.QUB"
PRODUCT_TYPE                   = EDR
PRODUCT_CREATION_TIME          = 2004-03-24T12:33:18.000
PRODUCER_INSTITUTION_NAME      = IAS
PI_PDS_USER_ID                 = BIBRING
SPACECRAFT_NAME                = "MARS EXPRESS"
MISSION_PHASE_NAME             = ""MC _PhasHASEe_ 1"1 ”

INSTRUMENT_NAME              = "Observatoire Mineralogie, Eau, Glaces, Activite"
INSTRUMENT_ID                  = OMEGA
INSTRUMENT_TYPE                = "IMAGING SPECTROMETER"
^INSTRUMENT_DESC               = "OMEGA_DESC.TXT"
^INSTRUMENT_CALIBRATION_DESC   = "OMEGA_CALIBRATION_DESC.TXT"
 
DATA_QUALITY_ID                = 3
DATA_QUALITY_DESC              = " from 0 to 3 depending on
                           missing lines and compression errors"
 
MISSING_SCAN_LINES             = 0
CHANNEL_ID                     = (IRC,IRL,VIS)
SOFTWARE_VERSION_ID            = "OMEGA 4.5"
TARGET_NAME                    = MARS
  
EDR stands for Experiment Data Records. The PRODUCT_CREATION_TIME element provides the time at which the geometry data product has been generated. 

The MISSION_PHASE_NAME indicates in which phase of the mission the data was acquired. Mission phases are: EV, IC (cruise phase), thenand then MC _PHASEhase _1 to N (Mars orbit).

Two files are referred to in the DOCUMENT directory: OMEGA_DESC.TXT and OMEGA_CALIBRATION_DESC.TXT which contain information on the instrument and on the ground calibration respectively.

The TARGET_NAME element provides the target of the observation. It can be MARS, PHOBOS, or DEIMOS. 
4.1.1.4 Descriptive Data Elements

In addition to the data identification elements, we included descriptive data elements that provide an overview of the observation geometry and some information on the data product generation process. 

      ORBIT_NUMBER

The ORBIT_NUMBER element is the number of the Mars Express orbit around Mars at observation time.

MAXIMUM_LATITUDE
MINIMUM_LATITUDE
EASTERNMOST_LONGITUDE
WESTERNMOST_LONGITUDE

The MAXIMUM_LATITUDE element specifies the northernmost latitude of the spatial area covered by the observation. The MINIMUM_LATITUDE element specifies the southernmost latitude of the spatial area covered by the observation. The EASTERNMOST_LONGITUDE element provides the maximum numerical value of planetocentric longitude of the spatial area covered by the observation, unless it crosses the prime meridian. The WESTERNMOST_LONGITUDE element provides the minimum numerical value of planetocentric longitude of the spatial area covered by the observation, unless it crosses the prime meridian. Angles are expressed in degrees.

SLANT_DISTANCE

The SLANT_DISTANCE element provides a measure of the distance, in kilometers, from the spacecraft to the center of the observation along the line of sight.

SOLAR_LONGITUDE
SOLAR_DISTANCE
SUB_SOLAR_LONGITUDE
SUB_SOLAR_LATITUDE

The SOLAR_LONGITUDE element provides the areocentric longitude of the Sun that is a measure of season on Mars, in degrees.
The SOLAR_DISTANCE element provides the value of the distance from the center of the observation to the apparent position of the Sun, in kilometer. The SUB_SOLAR_LONGITUDE and the SUB_SOLAR_LATITUDE elements provide respectively the longitude and the latitude of the sub-solar point at observation time. The sub-solar point is defined as the intersection point between the apparent position vector of the Sun in the Mars-fixed rotating frame, and the reference surface of Mars.

The following data elements contain information on the operating mode of OMEGA

COMMAND_NAME                   = "OMEGA_NOMINAL"
COMMAND_DESC                   = "00838383,00303030,04600900,050000EF,
                                                                     06001549,07708721,08000000,0900006F,0AEED804"

This indicates the series of hexadecimal commands whichcommands, which were sent to OMEGA for this particular data set. They control the operational modes

INSTRUMENT_MODE_ID             = ( 06,06,09)
EXPOSURE_DURATION                = (5.0,5.0, 50.0) <MS>
DOWNTRACK_SUMMING              = 1

INSTRUMENT_MODE_ID indicates the operating mode for each of the 3 channels of OMEGA (IRC, IRL, VIS). The mode is always the same for IRC and IRL, from 0 to 10. The VIS operating mode can range from 0 to 41.
       
	The table of modes for the SWIR channel is the following:
		0: NA
		1: 16 pixels, 2.5 msec
		2: 16 pixels, 5 msec
		3: 32pixels, 2.5 msec
		4: 32 pixels, 5 msec
		5: 64 pixels, 2.5 msec
		6: 64 pixels, 5 msec
		7: 128 pixels, 2.5 msec
		8: 128 pixels, 5 msec
		9: 128 pxels, 10 msec
	           10: 128 pixels, 20 msec (C channel), 10 msec (L channel)

	The table of modes for the VIS channel is the following:
		0 to 3: NA
		4, 5, 6: 128 pixels, nominal res, 200 msec, 100 msec, 50 msec int. time
		7, 8, 9:  64 pixels, nominal res, 200 msec, 100 msec, 50 msec int. time
		10,11,12: 64 pixels, high spectral res, 200 msec, 100 msec, 50 msec int. time
		13 to 18: NA (extended swath modes, not in the ESA database)
		19,20,21: 32 pixels, nominal res, 200 msec, 100 msec, 50 msec int. time
		22,23,24: 32 pixels, high spectral res, 200 msec, 100 msec, 50 msec int. time
		25 to 30: NA (extended swath modes, not in the ESA database)
		31, 32: 16 pixels, nominal res, 100 msec, 50 msec int. time
		33,34 : 16 pixels, high spectral res, 100 msec, 50 msec int. time
--> YL TO ADD A DETAILED DESCRIPTION OF INSTRUMENT MODE

INST_CMPRS_NAME                = "WAVELET"
INST_CMPRS_RATE                = 3.00

INST_CMPRS_NAME indicates which of the 3 types of compression was used for the data: NONE, REVERSIBLE or WAVELET. In the “WAVELET” compression mode, INST_CMPRS_RATE indicates the requested compression rate in bits per data. It is set as 12 for “NONE” and as 5 for “REVERSIBLE

OFFSET                          = 0.0
SCALING_FACTOR                   = 0.983

--> YL TO ADD A DESCRIPTION OF “OFFSET”?
Fixed parameters. The SCALING FACTOR indicates the IFOV ratio between the VIS and IR channels. OFFSET refers to the angular distance between the C and L channel in the scan direction, which is close to O



START_TIME                    = 2004-01-14T00:19:12.032
STOP_TIME                     = 2004-01-14T00:23:03.059
SPACECRAFT_CLOCK_START_COUNT  = "22054009.23265"
SPACECRAFT_CLOCK_STOP_COUNT   = "22054240.00630"

These times are obtained from the packet headers constituting an observation--> YL TO ADD A COMMENT ON HOW THESE TIMES ARE OBTAINED?

4.1.1.5 Data Object Definitions


The data object is a QUBE that does not fulfill ISIS standards. The binary data is constituted of a cube, 7 side planes in the X direction and 1 side plane in the Y direction. The data cube is coded as 16 bits signed integers (LSB_SIGNED_INTEGER). All side-planes are coded as 32 signed bits integers (LSB_SIGNED_INTEGER). The BAND dimension is nominally 352. It can reach 400 with the high spectral resolution mode of the 


Keyword
Definition
Typical value
AXES
Dimension of the qube
3
AXIS_NAME
Names of axes
(SAMPLE,BAND,LINE)
CORE_ITEMS 
Core dimensions of axes
(64,352,648)
CORE_ITEM_BYTES 
Core element size
2
CORE_ITEM_TYPE 
Core element type
LSB_SIGNED_INTEGER
CORE_BASE 
Base value item scaling*
0.0
CORE_MULTIPLIER 
Multiplier for core item scaling*
1.0
SUFFIX_BYTES
Storage allocation for suffix elements
4
SUFFIX_ITEMS
Suffix dimensions of axes
(1,7,0)
CORE_VALID_MINIMUM 
Minimum valid core value
"NULL"
CORE_NULL 
Special value indicating ‘invalid’ data
"NULL"
CORE_LOW_REPR_SATURATION 
Special value indicating representation saturation at low end**
-32768
CORE_LOW_INSTR_SATURATION 
Special value indicating instrument saturation at low end**
-32768
CORE_HIGH_REPR_SATURATION
Special value indicating representation saturation at high end**
32767
CORE_HIGH_INSTR_SATURATION
Special value indicating instrument saturation at high end**
32767
CORE_NAME 
Name of value stored in core
RAW_DATA_NUMBER
CORE_UNIT 
Unit of core values
DIMENSIONLESS
* true value = base + multiplier * stored value
** These keywords are required but not applicable in the case of the geometry data qube

Table 4: Science Data QQube Keywords Definition.

Among the keywords mentionned above, only CORE_ITEMS can take different values:

* The first dimension, named SAMPLE, refers to the length of scan. It can be 16, 32, 64, or 128 pixels. It gives the first spatial dimension.

* The second dimension, named BAND, refers to the number of spectral elements in each spectrum. It can be either 352 (nominal) or 400 (high VIS spectral resolution)

* The third dimension, named LINE, refers to the rank of the scan. It is the second spatial dimension.



* The third dimension, named LINE, refers to the rank of the scan. It is the second spatial dimension.Characteristics specific to OMEGA which are included in the label are:

* the orbit number
* the maximum and minimum latitude
* the easternmost and westernmost longitude
* the spacecraft altitude (set as 0 for 1b level products)
* the set of 8 hexadecimal commands which control the following observation parameters:
- instrument mode (IR and VIS)
- exposure duration (C, L and VIS channels)
- downtrack summing
- compression mode
- offset between visible and IR
- scan mode (nominal or fixed)
* the representative temperatures of the three focal planes
* the representative temperatures of the three spectrometers
The binary data is constituted of a cube, 7 side planes in the X direction and 1 side plane in the Y direction. The data cube is coded as 16 bits signed integers (SUN-INTEGER). 
* X dimension: scan (16, 32, 64 or 128 pixels)
* Y dimension: band (352 or 400  depending on the visible mode)
* Z dimension: line (rank of the scan)

All side-planes are coded as 32 signed bits integers (SUN-INTEGER)
Theere is one side plane added to the X spatial dimension (labelled “backplane” on the figure) c. It contains either 352 or 400 values for each scan, depending on the visible mode (352 for nominal, 400 for high spectral resolution). The first 256 values correspond to the dark current for the IR channels. The next 8 values correspond to dark currents of shielded spectels (2 at each end of the C and L IR channels). The next 88 or 136 values are given a constant value corresponding to the offset applied to the visible channel, which takes into account the operating temperature of the VIS CCD.

7 side planes are added to the band (spectral)Y dimension. For each scan, each of the seven side-lines has a dimension corresponding to the length of the scan (16, 32, 64 or 128). All information is included in the first 16 data, which correspond to the minimum length of these lines. The other data are set to 0. 




Figure 2: Conceptual view of the Science Data Qube

Comm : vérifier avec Joe s’il n’y a pas une inversion backplane/sideplane (commentaire de S. Slavney, mais je n’ai pas l’impression).


All analog values are expressed as a 32 bits signed integer:
- temperatures are expressed as multiples of 0.001 °C
- voltages are expressed as multiples of 0.001 V
- currents are expressed as multiples of 0.001 A

1st side plane: scanning mirror position (in Data Numbers coming out of the scanner monitoring device)

2nd side plane: information on the time at the beginning of the scan, in the following order:
    UT time: 7 values (year, month, day, hour, minute, second, millisecond)
    On-Board time: 2 values (seconds, milliseconds)
    SCET time:  4 values (2 for seconds, 2 for microseconds)

3rd side plane: selected temperatures 
     Temperature detector block C	 « SOA 5 »
     Temperature detector block L          	« SOA 6 »
     Temperature spectro C1		« SOA 1 »
     Temperature spectro C2                 	« SOA 2 »
     Temperature spectro L1		« SOA 3 »
     Temperature spectro L2                  	« SOA 4 »
     Temperature slit			« SOA 8 »
     Temperature detector C  		« SES 6 » (raw data)
     Temperature detector L 		« SES 14 » (raw data)

4th side plane: electronics and cooler temperatures
     Temperature spectro structure	«  SOA 9 »
     Temperature 190 K interface	             « SOA 10 »
     Temperature detector L (HR)	             « SOA 11 »
     Temperature SEP module		«  SEP 1 »
     Temperature electronics 1		«  SEA 3 »     
     Temperature electronics 2		«  SEA 4 »
     Temperature calibration source	«  SOA 7 »
     Temperature 280 K      		«    PF 1 »
     Temperature SKA motor C 		«  SKA 1 »
     Temperature SKA motor L 		«  SKA 2 »
     Temperature SKC C 		«  SKC 1 »
     Temperature SKC L 			«  SKC 2 »
     Temperature SES C			«  SES 5 »
     Temperature SES L			« SES 13 »
     Temperature SES			« SES 17 »

5th side plane: scanner, voltages, currents, status
     Temperature FOA			«  FEA 1 »
     Temperature FEA			«  FEA 2 »
      +12 V FEA		                  	«  SEP 2 »
     Voltage + 5V PF			«  SEA 5 »
     Voltage +15V PF			«  SEA 6 »
     Voltage –15V PF			«  SEA 7 »
     Status on-off			«  SEA 9 »
     Voltage motor C			«  SKA 3 »
     Current motor C			«  SKA 4 »
     Voltage motor L			«  SKA 5 »
     Current motor L			«  SKA 6 »
     Voltage setting C			«  SKA 7 »
     Voltage setting L		 	«  SKA 8 »
     Status 				«  SEA 10 » 
     Current (calibration source)		«  SEA 1 »  
     Voltage (calibration source 		«  SEA 2 »

6th « Side Plane » SES voltages 
     VGL1 C				«  SES 1 »
     PHIP LB C				«  SES 2 » 
     Polarization diode C			«  SES 3 »
     Video offset C			«  SES 4 »
     24 Volts C				«  SES 7 »
     constant offset C			«  SES 8 »
     VGL1 L				«  SES 9 »
     PHIP LB L				« SES 10 »
     Polarization diode L			« SES 11 »
     Video offset L			« SES 12 »
     24 Volts L				« SES 15 »
     constant offset			« SES 16 »

7th « side plane ”: VEA subsystem (visible channel)
    Setting 15 volts			«  VEA 2 »
    Setting –15 volts			«  VEA 3 »
    Setting 5 volts			«  VEA 1 »
    Setting –5 volts			«  VEA 4 »
    Temperature CCD			«  VEA 7 »
    Temperature optics			«  VEA 6 »
    Température electronics VEA		«  VEA 5 »
    Current (calibration source)		«  VEA 8 »
    Status calibration + test		« VEA 10 »
    Operation mode			« VEA 11 »
    Frame number			« VEA 12 »
    Command Echo 1			« VEA 13 »
    Command Echo 2			« VEA 14 »
    Number of transmitted blocks	             « VEA 15 »
    Number of spectral elements		« VEA 16 »

[details of the content of this data productetectors label, line by line]
1.1.1.1 4.36.1.1 File Characteristics Data Elements
1.1.1.1 4.36.1.2 Data Object Pointers Identification Data Elements
1.1.1.1 4.36.1.3 Instrument and Detector Descriptive Data Elements
1.1.1.1 4.36.1.4 Structure Definition of Instrument Parameter Objects 
1.1.1.1 4.36.1.5 Data Object Definition
1.1.1.1 4.36.1.6 Description of Instrument 
1.1.1.1 4.36.1.7 Parameters Index File Definition
1.1.1.1 4.36.1.8 Mission Specific Keywords
1.1.1 

4.1.2 4.36.2 Data Product B DesignGeometry Level-1B Data Product


A geometry data product is equal to a single data file, which has the PDS format. It contains the observation geometry of each pixel for each of the three OMEGA detectors.The data product label is attached at the beginning of the data product file. The following subsections describe in details the content of this label and the data object it is referring to. An example label for a geometry data product is provided in annex C.






















Figure 3: View of a geometry data product

4.1.2.1 File Characteristics Data Elements

PDS data product labels contain data element information that describes important attributes of the physical structure of a data product file. The PDS file characteristic data elements are:

RECORD_TYPE
RECORD_BYTES
FILE_RECORDS
LABEL_RECORDS
FILE_NAME

The RECORD_TYPE data element identifies the record characteristics of the data product file. Physical records are always fixed-length. The RECORD_BYTES data element identifies the number of bytes in each physical record in the data product file. Records length is always equal to 512 bytes. The FILE_RECORDS data element identifies the number of physical records in the file. The LABEL_RECORDS data element identifies the number of physical records that make up the PDS product label. The FILE_NAME data element identifies the name of the geometry file. 

The Planetary Science Archive of ESA implements the “Release” concept: data is delivered as units (releases), which can be updated (revision). Two specific data elements are included to handle the release concept: 

       RELEASE_ID
       REVISION_ID
	
     	RELEASE_ID defines the release number and REVISION_ID defines the revision number.

4.1.2.2 Data Object Pointers Identification Data Elements
 
The label refers to a single data object, which is a QUBE.  The data object starts in the next physical record after the PDS product label area. The data object pointer takes the following form:

^QUBE = nnn

where nnn represents the starting record number within the geometry file (first record is numbered 1).
4.1.2.3 Data Identification Elements

The following data identification elements provide additional information about the data product.

   DATA_SET_ID                   = "MEX-M-OMEGA-2-EDR-FLIGHT-V1.0"
   PRODUCT_ID                    = "ORB0018103_1_GEOMNAVPRE"
   PRODUCT_TYPE                  = EDR
   PRODUCT_CREATION_TIME         = 2004-09-29T08:46:38.098
   PRODUCER_INSTITUTION_NAME     = IAS
   PI_PDS_USER_ID                = BIBRING
   SPACECRAFT_NAME               = "MARS EXPRESS"
   MISSION_PHASE_NAME            = "MC PHASE 1"
   INSTRUMENT_ID                 = OMEGA
   TARGET_TYPE                   = PLANET
   TARGET_NAME                   = MARS
   		START_TIME                    = 2004-01-14T00:19:12.032
 		STOP_TIME                     = 2004-01-14T00:23:03.059
       SPACECRAFT_CLOCK_START_COUNT  = "22054009.23265"
       SPACECRAFT_CLOCK_STOP_COUNT   = "22054240.00630"
 
EDR stands for Experiment Data Records. The PRODUCT_CREATION_TIME element provides the time at which the geometry data product has been generated. The TARGET_NAME element provides the target of the observation. It can be MARS, PHOBOS, or DEIMOS.
4.1.2.4 Descriptive Data Elements

In addition to the data identification elements, we included descriptive data elements that provide an overview of the observation geometry and some information on the data product generation process. 

ORBIT_NUMBER
SPACECRAFT_POINTING_MODE
SPACECRAFT_ORIENTATION

The ORBIT_NUMBER element is the number of the Mars Express orbit around Mars at observation time.
The SPACECRAFT_POINTING_MODE element indicates the spacecraft-pointing mode during the observation. It can be NADIR, ALONGTRACK, ACROSSTRACK, or INERT. These values result from an analysis of orbit and attitude data at observation time. Let the +Zb axis be the pointing direction of the spacecraft. We assume a nadir-pointing mode when the +Zb axis is continuously pointing to the center of Mars. We assume the spacecraft is along-track pointing when the +Zb axis is lying on the s/c orbit plane and is separated from the vector pointing to the center of Mars by a constant offset angle. The across-track pointing is defined as follows: the +Zb axis is continuously lying on the plane perpendicular to s/c orbit plane and passing by the center of Mars and the spacecraft position. In other words, the +Zb axis is rotated about the spacecraft velocity vector by a constant offset angle. This angle is provided within the label by mean of the following keyword:

      MEX: OFFSET_ANGLE

In the last case, the spacecraft is 3-axes pointing or inertial pointing. This means that the spacecraft orientation is fixed with respect to stars background. If so, pointing coordinates in J2000 frame are provided by mean of the two following keywords:

      RIGHT_ASCENSION
      DECLINATION

The SPACECRAFT_ORIENTATION element indicates whether the +Yb axis is oriented towards the spacecraft velocity vector, (0,1,0), or in the opposite direction, (0,-1,0). See appendix ?55 to get further information on the spacecraft frame.

MAXIMUM_LATITUDE
MINIMUM_LATITUDE
EASTERNMOST_LONGITUDE
WESTERNMOST_LONGITUDE

The MAXIMUM_LATITUDE element specifies the northernmost latitude of the spatial area covered by the observation. The MINIMUM_LATITUDE element specifies the southernmost latitude of the spatial area covered by the observation. The EASTERNMOST_LONGITUDE element provides the maximum numerical value of planetocentric longitude of the spatial area covered by the observation, unless it crosses the prime meridian. The WESTERNMOST_LONGITUDE element provides the minimum numerical value of planetocentric longitude of the spatial area covered by the observation, unless it crosses the prime meridian. Angles are expressed in degrees.

SLANT_DISTANCE

The SLANT_DISTANCE element provides a measure of the distance, in kilometers, from the spacecraft to the center of the observation along the line of sight.

SOLAR_LONGITUDE
SOLAR_DISTANCE
SUB_SOLAR_LONGITUDE
SUB_SOLAR_LATITUDE

The SOLAR_LONGITUDE element provides the areocentric longitude of the Sun that is a measure of season on Mars, in degrees.
The SOLAR_DISTANCE element provides the value of the distance from the center of the observation to the apparent position of the Sun, in kilometer. The SUB_SOLAR_LONGITUDE and the SUB_SOLAR_LATITUDE elements provide respectively the longitude and the latitude of the sub-solar point at observation time. The sub-solar point is defined as the intersection point between the apparent position vector of the Sun in the Mars-fixed rotating frame, and the reference surface of Mars.

^DATA_DESC = "GEOCUBE_DESC.TXT"

The DATA_DESC pointer provides the name of the file describing the content of the geometry data qube.

DATA_QUALITY_ID
SOFTWARE_NAME
SPICE_FILE_NAME

The DATA_QUALITY_ID element is always “NULL”. The SOFTWARE_NAME element indicates the name and the version number of the software that has been used to generate the geometry data product. The SPICE_FILE_NAME element provides the list of all the SPICE kernels required and used to generate the geometry data product of concern.
4.1.2.5 Data Object Definitions

The data object is a QUBE that does not fulfill ISIS standards. Unlike science level-1B data qubes, geometry qubes do not hold suffix areas, but have the same core structure. This core is a three-dimensional array with two spatial dimensions, and one dimension used to store the observation geometry parameters. The qube’s structure and attributes are described by the following keywords:

Keyword
Definition
Typical value
AXES
Dimension of the qube
3
AXIS_NAME
Names of axes
(SAMPLE,BAND,LINE)
CORE_ITEMS 
Core dimensions of axes
(128,51,648)
CORE_ITEM_BYTES 
Core element size
4
CORE_ITEM_TYPE 
Core element type
LSB_SIGNED_INTEGER
CORE_BASE 
Base value item scaling*
0.0
CORE_MULTIPLIER 
Multiplier for core item scaling*
1.0
SUFFIX_BYTES
Storage allocation for suffix elements
4
SUFFIX_ITEMS
Suffix dimensions of axes
(0,0,0)
CORE_VALID_MINIMUM 
Minimum valid core value
"NULL"
CORE_NULL 
Special value indicating ‘invalid’ data
"NULL"
CORE_LOW_REPR_SATURATION 
Special value indicating representation saturation at low end**
-2147483648
CORE_LOW_INSTR_SATURATION 
Special value indicating instrument saturation at low end**
-2147483648
CORE_HIGH_REPR_SATURATION
Special value indicating representation saturation at high end**
2147483647
CORE_HIGH_INSTR_SATURATION
Special value indicating instrument saturation at high end**
2147483647
CORE_NAME 
Name of value stored in core
RAW_DATA_NUMBER
CORE_UNIT 
Unit of core values
DIMENSIONLESS
* true value = base + multiplier * stored value
** These keywords are required but not applicable in the case of the geometry data qube

Table 552: Geometry Qube Keywords Definition.

Among the keywords mentionned above, only CORE_ITEMS can take different values:

* The first dimension, named SAMPLE, refers to the length of scan. It can be 16, 32, 64, or 128 pixels. It gives the first spatial dimension.

* The second dimension, named BAND, actually refers to the 51 parameters describing the geometry of  the observation of concern.

* The third dimension, named LINE, refers to the rank of the scan. It is the second spatial dimension.

The first and third dimensions are the same as that of the corresponding science level-1B data cube. From geometry planes, one value of the corresponding parameter is associated to each of the spectra in the science level-1B data cubes. There is an exception to this: the second plane is used to store information on time at the beginning of the IR scan.

The following table lists the parameters contained within the data cube, which describes the geometry of an OMEGA observation:


#
Parameter	
Unit

1
IR scan mirror position
DIMENSIONLESS

2
time at the beginning of the IR scan
See note 1
SWIR-C
3
incidence angle w.r.t the outward normal to the reference ellipsoid
0.0001 <DEG>

4
emergence angle w.r.t the outward normal to the reference ellipsoid
0.0001 <DEG>

5
incidence angle w.r.t the opposite direction of the center of Mars
0.0001 <DEG>

6
emergence angle w.r.t the opposite direction of the center of Mars
0.0001 <DEG>

7
longitude of the pixel footprint center point
0.0001 <DEG>

8
latitude of the pixel footprint center point
0.0001 <DEG>

9
incidence angle w.r.t the local normal2
0.0001 <DEG>

10
emergence angle w.r.t the local normal2
0.0001 <DEG>

11
phase angle w.r.t the local normal2
0.0001 <DEG>

12
slant distance from the spacecraft to pixel footprint center point
<METER>

13
elevation of the pixel footprint center point2
<METER>

14-17
longitude of the 4 pixel footprint corner points
0.0001 <DEG>

18-21
latitude of the 4 pixel footprint corner points
0.0001 <DEG>
SWIR-L
22-36
same information as plane 7-21 for SWIR-L channel

VNIR
37-51
same information as plane 7-21 for VNIR channel

1Time information format:

UT	year, month, day, hour, minute, second, millisecond (7 values)
OBT	seconds, milliseconds (2 values)
SCET	seconds (2 values), microseconds (2 values)

2In the case of limb observations, incidence and emergence angles (planes number 9,10,24,25,39, and 40) are computed with respect to the opposite direction of the center of Mars instead of using local topography. Also, planes number 13, 28, and 43 are replaced with the altitude of the central tangent point above the surface of Mars, plus an offset equal to 65536.

For further information on observation geometry please refer to appendix ?55.

Table 6: Geometry Data Qube Parameters Description



Figure 4: Conceptual view of the Geometry Data Qube
5 
Appendixnnex Appendix: Geometrical Parameters Definition

Pixel footprint

A pixel footprint is the figure on the surface of Mars resulting from the projection (intersection) of the pixel’s field of view boundary vectors onto the surface. Intersection/impact points coordinates on the surface define the pixel footprint. Indeed, although the term of pixel footprint does not make so much sense in the case of a limb observation, we use it to describe the figure on the surface defined the four boundary impact points. Note that the pixel footprint center point is the intersection point between the pixel boresight and the surface of Mars (surface observation), or the impact point built from the pixel boresight (limb observation).

Impact and tangent point

An impact point is the intersection between the vector from the center of Mars to a tangent point and a reference surface.
A tangent point is the closest point to the center of Mars (center of mass) lying on the pixel boresight. We use the term of tangent point only when the pixel field of view boundary vectors do not intersect the surface.





























Figure 5: Overview of pixel observation geometry

Incidence angle

The incidence angle (i) is the angle between the “surface” normal vector at the intercept/impact point (surface) and the vector from the intercept/impact point to the Sun.



Emergence angle 

Also called emission angle (e), this angle is the angle between the “surface” normal vector at the intercept/ impact point and the vector from intercept/ impact point to the spacecraft.

Phase angle

The phase angle (?) is the angle between the vector from the intercept/impact point to the Sun, and the vector from the intercept/impact point to the spacecraft.


Spacecraft "mechanical/structure” frame

The "mechanical/structure frame" frame (Xb,Yb,Zb), with respect to which orientation of all science instruments and spacecraft structures are defined, is called MEX_SPACECRAFT frame in the MEX SPICE implementation.

This frame is defined as follows:

the payloads are located on the +Zb axis (the Main Engine being on the -Zb axis);
* the HGA is located on -Xb axis;
* the +Y axis is defined so that the (Xb,Yb,Zb) frame is right-handed.
* the origin of this frames is the launch vehicle interface point.





6 
Appendix nneppendi B: Example of PDS label of an OMEGA 1B data product

PDS_VERSION_ID                 = 3
LABEL_REVISION_NOTE            = "2004-09-03, YL-BG-JZ"
  /* File format and length */
RECORD_TYPE                    = FIXED_LENGTH
RECORD_BYTES                   = 512
FILE_RECORDS                   = 54299  
LABEL_RECORDS                  = 11 
FILE_NAME                      = "ORB0018_0.QUB"
^QUBE                          = 12  
DATA_SET_ID                    = "MEX-M-OMEGA-2-EDR-FLIGHT-V1.0"
RELEASE_ID                     = 0001
REVISION_ID                    = 0000
PRODUCT_ID                     = "ORB0018_0_DATA"
PRODUCT_TYPE                   = EDR
STANDARD_DATA_PRODUCT_ID       = "OMEGA DATA"
PI_PDS_USER_ID                 = BIBRING
MISSION_NAME                   = "MARS EXPRESS"
MISSION_PHASE_NAME             = "MC PHASE 1"
INSTRUMENT_NAME                = "Observatoire Mineralogie, Eau, Glaces, Activite"
PRODUCER_INSTITUTION_NAME      = "IAS"
INSTRUMENT_ID                  = OMEGA
INSTRUMENT_TYPE                = "IMAGING SPECTROMETER"
^INSTRUMENT_DESC               = "OMEGA_DESC.TXT"
^INSTRUMENT_CALIBRATION_DESC   = "OMEGA_CALIBRATION_DESC.TXT"
 
DATA_QUALITY_ID                = 3
DATA_QUALITY_DESC              = " from 0 to 3 depending on
                                 missing lines and compression errors"
 
MISSING_SCAN_LINES             = 0
CHANNEL_ID                     = (IRC,IRL,VIS)
SOFTWARE_VERSION_ID            = "OMEGA 4.5"
TARGET_NAME                    = MARS
ORBIT_NUMBER                   = 18
 
PRODUCT_CREATION_TIME          = 2004-09-29T08:46:38.098
START_TIME                     = 2004-01-14T00:19:12.032
STOP_TIME                      = 2004-01-14T00:23:03.059
SPACECRAFT_CLOCK_START_COUNT   = "22054009.23265"
SPACECRAFT_CLOCK_STOP_COUNT    = "22054240.00630"
 
MAXIMUM_LATITUDE               = -54.594
MINIMUM_LATITUDE               = -65.256
EASTERNMOST_LONGITUDE          = 322.959
WESTERNMOST_LONGITUDE          = 318.126
SLANT_DISTANCE                 = 1112.726
 
/* set of commands */
COMMAND_NAME                   = "OMEGA_NOMINAL"
COMMAND_DESC                   = "00838383,00303030,04600900,050000EF,
    06001549,07708721,08000000,0900006F,0AEED804"
 
/* instrument status */
INSTRUMENT_MODE_ID             = ( 06,06,09)
EXPOSURE_DURATION              = (5.0,5.0, 50.0) <ms>
DOWNTRACK_SUMMING              = 1
 
INST_CMPRS_NAME                = "WAVELET"
INST_CMPRS_RATE                = 3.00
OFFSET                         = 0.0
SCALING_FACTOR                 = 0.983
 
MEX:SCAN_MODE_ID               = NOMINAL
                 /* can be "FIXED" OR "DEFAULT" */
MEX:FOCAL_PLANE_TEMPERATURE    = ( 77.6, 77.5,274.6) <K>
MEX:FOCAL_PLANE_TEMPERATURE_DESC=" temperatures of the C, L, V detectors"
MEX:SPECTROMETER_TEMPERATURE   = (182.9,181.0,191.7) <K>
MEX:SPECTROMETER_TEMPERATURE_DESC=" temperatures of the C, L, V spectrometers"
OBJECT                         = QUBE
 
/* ISIS cube with non-standard sideplanes */
AXES                           = 3
AXIS_NAME                      = (SAMPLE,BAND,LINE)
 
CORE_ITEMS                     = ( 64,352,576)
CORE_NAME                      = "RAW DATA NUMBER"
CORE_UNIT                      = "N/A"
CORE_ITEM_TYPE                 = LSB_SIGNED_INTEGER
CORE_ITEM_BYTES                = 2
CORE_BASE                      = 0.0
CORE_MULTIPLIER                = 1.0
CORE_VALID_MINIMUM             = "N/A"
CORE_NULL                      = "N/A"
CORE_LOW_REPR_SATURATION       = -32768
CORE_LOW_INSTR_SATURATION      = -32768
CORE_HIGH_REPR_SATURATION      = 32767
CORE_HIGH_INSTR_SATURATION     = 32767
 
/* suffix definitions for OMEGA */
SUFFIX_BYTES                   = 4
SUFFIX_ITEMS                   = (1,7,0) /* number of sideplanes */
 
SAMPLE_SUFFIX_NAME             = "DARK"
SAMPLE_SUFFIX_UNIT             = "N/A"
SAMPLE_SUFFIX_ITEM_TYPE        = LSB_SIGNED_INTEGER
SAMPLE_SUFFIX_ITEM_BYTES       = 4
SAMPLE_SUFFIX_BASE             = 0.0
SAMPLE_SUFFIX_MULTIPLIER       = 1.0
SAMPLE_SUFFIX_VALID_MINIMUM    = "N/A"
SAMPLE_SUFFIX_NULL             = "N/A"
SAMPLE_SUFFIX_LOW_REPR_SAT     = -32768
SAMPLE_SUFFIX_LOW_INSTR_SAT    = -32768
SAMPLE_SUFFIX_HIGH_REPR_SAT    = 32767
SAMPLE_SUFFIX_HIGH_INSTR_SAT   = 32767
SAMPLE_SUFFIX_NOTE             = "The sample sideplane contains the offset spectrum
       subtracted after acquisition. Visible: constant value"
 
BAND_SUFFIX_NAME               = "HOUSEKEEPING_PARAMETERS"
BAND_SUFFIX_UNIT               = "N/A"
BAND_SUFFIX_ITEM_TYPE          = LSB_SIGNED_INTEGER
BAND_SUFFIX_ITEM_BYTES         = 4
BAND_SUFFIX_BASE               = 0.0
BAND_SUFFIX_MULTIPLIER         = 1.0
BAND_SUFFIX_VALID_MINIMUM      = "N/A"
BAND_SUFFIX_NULL               = "N/A"
BAND_SUFFIX_LOW_REPR_SAT       = -32768
BAND_SUFFIX_LOW_INSTR_SAT      = -32768
BAND_SUFFIX_HIGH_REPR_SAT      = 32767
BAND_SUFFIX_HIGH_INSTR_SAT     = 32767
BAND_SUFFIX_NOTE               = "Housekeeping parameters and sideplane structure
                              are detailed in the OMEGA EAICD document"
^HOUSEKEEPING_DESCRIPTION      = "OMEGA_HK.TXT"
 
END_OBJECT                     = QUBE
END
 PDS_VERSION_ID                 = 3
LABEL_REVISION_NOTE            = "2004-09-03, YL-BG-JZ"
  /* File format and length */
RECORD_TYPE                    = FIXED_LENGTH
RECORD_BYTES                   = 512
FILE_RECORDS                   = 54299  
LABEL_RECORDS                  = 11 
FILE_NAME                      = "ORB0018_0.QUB"
^QUBE                          = 12  
DATA_SET_ID                    = "MEX-M-OMEGA-2-EDR-FLIGHT-V1.0"
RELEASE_ID                     = 0001
REVISION_ID                    = 0000
PRODUCT_ID                     = "ORB0018_0_DATA"
PRODUCT_TYPE                   = EDR
STANDARD_DATA_PRODUCT_ID       = "OMEGA DATA"
PI_PDS_USER_ID                 = BIBRING
MISSION_NAME                   = "MARS EXPRESS"
MISSION_PHASE_NAME             = "MC_Phase_1 "
INSTRUMENT_NAME                = "Observatoire Mineralogie, Eau, Glaces, Activite"
PRODUCER_INSTITUTION_NAME      = "IAS"
INSTRUMENT_ID                  = OMEGA
INSTRUMENT_TYPE                = "IMAGING SPECTROMETER"
^INSTRUMENT_DESC               = "OMEGA_DESC.TXT"
^INSTRUMENT_CALIBRATION_DESC   = "OMEGA_CALIBRATION_DESC.TXT"
 
DATA_QUALITY_ID                = 3
DATA_QUALITY_DESC              = " from 0 to 3 depending on
                           missing lines and compression errors"
 
MISSING_SCAN_LINES             = 0
CHANNEL_ID                     = (IRC,IRL,VIS)
SOFTWARE_VERSION_ID            = "OMEGA 4.5"
TARGET_NAME                    = MARS
ORBIT_NUMBER                   = 18
 
PRODUCT_CREATION_TIME          = 2004-09-23T15:25:21.006
START_TIME                     = 2004-01-14T00:19:12.032
STOP_TIME                      = 2004-01-14T00:23:03.059
SPACECRAFT_CLOCK_START_COUNT   = "22054009.23265"
SPACECRAFT_CLOCK_STOP_COUNT    = "22054240.00630"
 
MAXIMUM_LATITUDE               = -63.879
MINIMUM_LATITUDE               = -64.568
EASTERNMOST_LONGITUDE          = 322.320
WESTERNMOST_LONGITUDE          = 318.376
SLANT_DISTANCE                 = 1256.562
 
/* set of commands */
COMMAND_NAME                   = "OMEGA_NOMINAL"
COMMAND_DESC                   = "00838383,00303030,04600900,050000EF,
    06001549,07708721,08000000,0900006F,0AEED804"
 
/* instrument status */
INSTRUMENT_MODE_ID             = ( 06,06,09)
EXPOSURE_DURATION              = (5.0,5.0, 50.0) <MS>
DOWNTRACK_SUMMING              = 1
 
INST_CMPRS_NAME                = "WAVELET"
INST_CMPRS_RATE                = 3.00
OFFSET                         = 0.0
SCALING_FACTOR                 = 0.983
 
MEX:SCAN_MODE_ID               = NOMINAL
                 /* can be "FIXED" OR "DEFAULT" */
MEX:FOCAL_PLANE_TEMPERATURE    = ( 77.6, 77.5,274.6) <K>
MEX:FOCAL_PLANE_TEMPERATURE_DESC=" temperatures of the C, L, V detectors"
MEX:SPECTROMETER_TEMPERATURE   = (182.9,181.0,191.7) <K>
MEX:SPECTROMETER_TEMPERATURE_DESC=" temperatures of the C, L, V spectrometers"
OBJECT                         = QUBE
 
/* ISIS cube with non-standard sideplanes */
AXES                           = 3
AXIS_NAME                      = (SAMPLE,BAND,LINE)
CORE_ITEMS                     = ( 64,352,576)
CORE_ITEM_BYTES                = 2
CORE_ITEM_TYPE                 = LSB_SIGNED_INTEGER
CORE_BASE                      = 0.0
CORE_MULTIPLIER                = 1.0
CORE_VALID_MINIMUM             = N/A
CORE_NULL                      = N/A
CORE_LOW_REPR_SATURATION       = -32768
CORE_LOW_INSTR_SATURATION      = -32768
CORE_HIGH_REPR_SATURATION      = 32767
CORE_HIGH_INSTR_SATURATION     = 32767
CORE_NAME                      = "RAW DATA NUMBER"
CORE_UNIT                      = DIMENSIONLESS
 
/* suffix definitions for OMEGA */
SUFFIX_BYTES                   = 4
SUFFIX_ITEMS                   = (1,7,0) /* number of sideplanes */
 
SAMPLE_SUFFIX_NAME             = "DARK"
SAMPLE_SUFFIX_UNIT             = DIMENSIONLESS
SAMPLE_SUFFIX_ITEM_TYPE        = LSB_SIGNED_INTEGER
SAMPLE_SUFFIX_ITEM_BYTES       = 4
SAMPLE_SUFFIX_BASE             = 0.0
SAMPLE_SUFFIX_MULTIPLIER       = 1.0
SAMPLE_SUFFIX_VALID_MINIMUM    = "N/A"
SAMPLE_SUFFIX_NULL             = "N/A"
SAMPLE_SUFFIX_LOW_REPR_SAT     = -32768
SAMPLE_SUFFIX_LOW_INSTR_SAT    = -32768
SAMPLE_SUFFIX_HIGH_REPR_SAT    = 32767
SAMPLE_SUFFIX_HIGH_INSTR_SAT   = 32767
SAMPLE_SUFFIX_NOTE             = "The sample sideplane contains the offset spectrum
       subtracted after acquisition. Visible: constant value"
 
BAND_SUFFIX_NAME               = "HOUSEKEEPING_PARAMETERS"
BAND_SUFFIX_UNIT               = DIMENSIONLESS
BAND_SUFFIX_ITEM_TYPE          = LSB_SIGNED_INTEGER
BAND_SUFFIX_ITEM_BYTES         = 4
BAND_SUFFIX_BASE               = 0.0
BAND_SUFFIX_MULTIPLIER         = 1.0
BAND_SUFFIX_VALID_MINIMUM      = "N/A"
BAND_SUFFIX_NULL               = "N/A"
BAND_SUFFIX_LOW_REPR_SAT       = -32768
BAND_SUFFIX_LOW_INSTR_SAT      = -32768
BAND_SUFFIX_HIGH_REPR_SAT      = 32767
BAND_SUFFIX_HIGH_INSTR_SAT     = 32767
BAND_SUFFIX_NOTE               = "Housekeeping parameters and sideplane structure
                              are detailed in the OMEGA EAICD document"
^HOUSEKEEPING_DESCRIPTION      = "OMEGA_HK.TXT"
 
END_OBJECT                     = QUBE
END
                                                                                         
1 
PDS_VERSION_ID                           = 3
1 LABEL_REVISION_NOTE                      = "2003-10-03, YL-BG"
1   /* File format and length */
1 RECORD_TYPE                              = FIXED_LENGTH
1 RECORD_BYTES                             = 512
1 FILE_RECORDS                             = 138748  
1 LABEL_RECORDS                            = 12 
1 FILE_NAME                                = "ORB0103_0.QUB"
1 ^QUBE                                    = 13 
1 DATA_SET_ID                              = "MEX-M-OMEGA-2-EDR-0000-0010-V1.0"
1 PRODUCT_ID                               = TEST
1 PRODUCT_TYPE                             = EDR
1 PI_PDS_USER_ID                           = BIBRING
1 MISSION_NAME                             = "MARS_EXPRESS"
1 MISSION_PHASE_NAME                       = "NOMINAL"
1 INSTRUMENT_NAME                          = "Observatoire Mineralogie, Eau, Glaces, Activite"
1 PRODUCER_INSTITUTION_NAME                = IAS
1 INSTRUMENT_ID                            = OMEGA
1 INSTRUMENT_TYPE                          = "IMAGING_SPECTROMETER"
1 ^INSTRUMENT_DESC                         = "OMEGA_DESC.TXT"
1 ^INSTRUMENT_CALIBRATION_DESC             = "OMEGA_CALIBRATION_DESC.TXT"
1  
1 DATA_QUALITY_ID                          = N/A
1  
1 MISSING_SCAN_LINES                       = 00
1 CHANNEL_ID                               = {IRC,IRL,VIS}
1 SOFTWARE_VERSION_ID                      = OMEGA_4_5
1 TARGET_NAME                              = MARS
1 ORBIT_NUMBER                             = 103
1  
1 PRODUCT_CREATION_TIME                    = 2004-02-13T00:21:24.05
1 START_TIME                               = 2004-02-11T16:31:02.38
1 STOP_TIME                                = 2004-02-11T16:40:53.25
1 SPACECRAFT_CLOCK_START_COUNT             = 24597055.430
1 SPACECRAFT_CLOCK_STOP_COUNT              = 24597646.305
1  
1 MAXIMUM_LATITUDE                         = -62.913
1 MINIMUM_LATITUDE                         = -78.362
1 EASTERNMOST_LONGITUDE                    = 184.864
1 WESTERNMOST_LONGITUDE                    = 166.612
1 SPACECRAFT_ALTITUDE                      = 2627.957
1  
1 /* set of commands */
1 COMMAND_NAME                             = OMEGA_NOMINAL
1 COMMAND_DESC                             = "00838383,00101010,04600900,050000EF,
1     06001549,07708721,08000000,0900006F,0AEED804"
1  
1 /* instrument status */
1 INSTRUMENT_MODE_ID                       = IR_06_VIS_09
1 EXPOSURE_DURATION                        = {5.0,5.0, 50.0} <ms>
1 DOWNTRACK_SUMMING                        = 1
1  
1 INST_CMPRS_NAME                          = "WAVELET"
1 INST_CMPRS_RATE                          = 1.00
1 OFFSET                                   = 0.0
1 SCALING_FACTOR                           = 0.983
1  
1 GROUP                                    = MEX_PARAMETERS
1 SCAN_MODE_ID                             = NOMINAL   /* can be "FIXED" OR "DEFAULT" */
1 FOCAL_PLANE_TEMPERATURE                  = { 77.7, 77.1,274.0} <K>
1 SPECTROMETER_TEMPERATURE                 = {180.3,178.6,189.3} <K>
1 END_GROUP                                = MEX_PARAMETERS
1 OBJECT                                   = QUBE
1  
1 /* ISIS cube with non-standard sideplanes */
1 AXES                                     = 3
1 AXIS_NAME                                = (SAMPLE,BAND,LINE)
1 CORE_ITEMS                               = ( 64,352,1472)
1 CORE_ITEM_BYTES                          = 2
1 CORE_ITEM_TYPE                           = LSB_SIGNED_INTEGER
1 CORE_BASE                                = 0.0
1 CORE_MULTIPLIER                          = 1.0
1 CORE_VALID_MINIMUM                       = N/A
1 CORE_NULL                                = N/A
1 CORE_LOW_REPR_SATURATION                 = -32768
1 CORE_LOW_INSTR_SATURATION                = -32768
1 CORE_HIGH_REPR_SATURATION                = 32767
1 CORE_HIGH_INSTR_SATURATION               = 32767
1 CORE_NAME                                = RAW_DATA_NUMBER
1 CORE_UNIT                                = DIMENSIONLESS
1  
1 /* suffix definitions for OMEGA */
1 SUFFIX_BYTES                             = 4
1 SUFFIX_ITEMS                             = (1,7,0) /* number of sideplanes */
1  
1 SAMPLE_SUFFIX_NAME                       = DARK
1 SAMPLE_SUFFIX_UNIT                       = DIMENSIONLESS
1 SAMPLE_SUFFIX_ITEM_TYPE                  = LSB_SIGNED_INTEGER
1 SAMPLE_SUFFIX_ITEM_BYTES                 = 4
1 SAMPLE_SUFFIX_BASE                       = 0.0
1 SAMPLE_SUFFIX_MULTIPLIER                 = 1.0
1 SAMPLE_SUFFIX_VALID_MINIMUM              = N/A
1 SAMPLE_SUFFIX_NULL                       = N/A
1 SAMPLE_SUFFIX_LOW_REPR_SAT               = -32768
1 SAMPLE_SUFFIX_LOW_INSTR_SAT              = -32768
1 SAMPLE_SUFFIX_HIGH_REPR_SAT              = 32767
1 SAMPLE_SUFFIX_HIGH_INSTR_SAT             = 32767
1 SAMPLE_SUFFIX_NOTE                       = "The sample sideplane contains the offset spectrum"
1        subtracted after acquisition. Visible: constant value
1  
1 BAND_SUFFIX_NAME                         = HOUSEKEEPING_PARAMETERS
1 BAND_SUFFIX_UNIT                         = DIMENSIONLESS
1 BAND_SUFFIX_ITEM_TYPE                    = LSB_SIGNED_INTEGER
1 BAND_SUFFIX_ITEM_BYTES                   = 4
1 BAND_SUFFIX_BASE                         = 0.0
1 BAND_SUFFIX_MULTIPLIER                   = 1.0
1 BAND_SUFFIX_VALID_MINIMUM                = N/A
1 BAND_SUFFIX_NULL                         = N/A
1 BAND_SUFFIX_LOW_REPR_SAT                 = -32768
1 BAND_SUFFIX_LOW_INSTR_SAT                = -32768
1 BAND_SUFFIX_HIGH_REPR_SAT                = 32767
1 BAND_SUFFIX_HIGH_INSTR_SAT               = 32767
1 BAND_SUFFIX_NOTE                         = "Housekeeping parameters and sideplane structure"
1        are detailed in the document OMEGA_HK.TXT
1 HOUSEKEEPING_DESCRIPTION                 = "OMEGA_HK.TXT"
1  
1 GROUP                                    = BAND_BIN
1 BAND_BIN_CENTER                          = N/A
1 BAND_BIN_UNIT                            = micrometer
1 BAND_BIN_ORIGINAL_BAND                   = N/A
1 END_GROUP                                = BAND_BIN
1  
1 END_OBJECT                               = QUBE
1 END
1 
1 
1 Comm : 
1 1) Les mots-clefs spécifiques devraient tous être dans le groupe MEX_PARAMETERS (ça inclut set of commands, + quelques uns dans instrument status).
1 2) SCALING_FACTOR n’est apparemment pas acceptable dans ce sens-là (ce devrait être une constante de conversion pour tous les canaux). Il vaut mieux inventer un autre mot-clef, genre VISIBLE_TO_IR_RATIO.
7 Appendix C: Example of PDS label of a level-1B geometry data product 
3) Idem pour OFFSET, qui serait mieux documenté par VISIBLE_TO_IR_OFFSAnnex CAppendix
PDS_VERSION_ID                = 3
LABEL_REVISION_NOTE           = "22-SEP-2004, N. Manaud"

/* FILE CHARACTERISTICS */
RECORD_TYPE                   = FIXED_LENGTH
RECORD_BYTES                  = 512
FILE_RECORDS                  = 14695  
LABEL_RECORDS                 = 7  
FILE_NAME                     = "ORB0018_0.NAV"
RELEASE_ID                    = 0001
REVISION_ID                   = 0000

/* DATA OBJECT POINTER /*
^QUBE                         = 8 

/* IDENTIFICATION DATA ELEMENTS */
DATA_SET_ID                   = "MEX-M-OMEGA-2-EDR-FLIGHT-V1.0"
PRODUCT_ID                    = "ORB0018_0_GEOM"
PRODUCT_TYPE                  = EDR
STANDARD_DATA_PRODUCT_ID      = "OMEGA GEOMETRY"
PRODUCT_CREATION_TIME         = 2004-09-29T17:14:02.000
PRODUCER_INSTITUTION_NAME     = IAS
PI_PDS_USER_ID                = BIBRING
SPACECRAFT_NAME               = "MARS EXPRESS"
MISSION_PHASE_NAME            = "MC PHASE 1" 
INSTRUMENT_NAME               = "Observatoire Mineralogie, Eau, Glaces, Activite"
INSTRUMENT_ID                 = OMEGA
TARGET_TYPE                   = PLANET
TARGET_NAME                   = MARS
START_TIME                    = 2004-01-14T00:19:12.032
STOP_TIME                     = 2004-01-14T00:23:03.059
SPACECRAFT_CLOCK_START_COUNT  = "22054009.23265"
SPACECRAFT_CLOCK_STOP_COUNT   = "22054240.00630"

/* DESCRIPTIVE DATA ELEMENTS */
ORBIT_NUMBER                  = 18
SPACECRAFT_POINTING_MODE      = "NADIR"
SPACECRAFT_POINTING_MODE_DESC = "The NADIR pointing mode is used for science observations
                                 nominally around the pericentre. In this pointing mode the
                                 Z-axis of the spacecraft points towards the centre of Mars
                                 and the X-axis perpendicular to the ground track."
^MEX_ORIENTATION_DESC         = "MEX_ORIENTATION_DESC.TXT"
MAXIMUM_LATITUDE              = -54.594
MINIMUM_LATITUDE              = -65.256
EASTERNMOST_LONGITUDE         = 322.959
WESTERNMOST_LONGITUDE         = 318.126
SLANT_DISTANCE                = 1112.73
SOLAR_LONGITUDE               = 333.1
SOLAR_DISTANCE                = 223058058.31
SUB_SOLAR_LONGITUDE           = 297.174
SUB_SOLAR_LATITUDE            = -11.118
^DATA_DESC                    = "GEOCUBE_DESC.TXT"
DATA_QUALITY_ID               = "NULL"
SOFTWARE_NAME                 = "GEOMEG V4 / 2"
SPICE_FILE_NAME               = "ATNM_P030602191822_00088.BC,
                                 ORMM__031222180906_00052.BSP,
                                 MEX_040730_STEP.TSC,
                                 MEX_OMEGA_V04.TI,
                                 MEX_V05.TF,
                                 DE405S.BSP,
                                 MAR033_2000-2025.BSP,
                                 MARS_IAU2000_v0.TPC,
                                 NAIF0007.TLS"

/* DATA OBJECT DEFINITIONS */
OBJECT                        = QUBE
  AXES                        = 3
  AXIS_NAME                   = (SAMPLE,BAND,LINE)
  CORE_ITEMS                  = (64,51,576)
  CORE_ITEM_BYTES             = 4
  CORE_ITEM_TYPE              = LSB_SIGNED_INTEGER
  CORE_BASE                   = 0.0
  CORE_MULTIPLIER             = 1.0
  SUFFIX_BYTES                = 4
  SUFFIX_ITEMS                = (0,0,0)
  CORE_VALID_MINIMUM          = "NULL"
  CORE_NULL                   = "NULL"
  CORE_LOW_REPR_SATURATION    = -2147483648
  CORE_LOW_INSTR_SATURATION   = -2147483648
  CORE_HIGH_REPR_SATURATION   =  2147483647
  CORE_HIGH_INSTR_SATURATION  =  2147483647
  CORE_NAME                   = "RAW DATA NUMBER"
  CORE_UNIT                   = DIMENSIONLESS
END_OBJECT                    = QUBE

END


/* LABEL STANDARDS */
PDS_VERSION_ID                = 3
LABEL_REVISION_NOTE           = "22-SEP-2004, N. Manaud"

/* FILE CHARACTERISTICS */
RECORD_TYPE                   = FIXED_LENGTH
RECORD_BYTES                  = 512
FILE_RECORDS                  = 798    
LABEL_RECORDS                 = 7  
FILE_NAME                     = "ORB0018_0.NAV"
RELEASE_ID                    = 0001
REVISION_ID                   = 0000

/* DATA OBJECT POINTER /*
^QUBE                         = 8 

/* IDENTIFICATION DATA ELEMENTS */
DATA_SET_ID                   = "MEX-M-OMEGA-2-EDR-FLIGHT-V1.0"
PRODUCT_ID                    = "ORB0018_0_GEOM"
PRODUCT_TYPE                  = EDR
STANDARD_DATA_PRODUCT_ID      = "OMEGA GEOMETRY"
PRODUCT_CREATION_TIME         = 2004-09-24T14:03:09.000
PRODUCER_INSTITUTION_NAME     = IAS
PI_PDS_USER_ID                = BIBRING
SPACECRAFT_NAME               = "MARS EXPRESS"
MISSION_PHASE_NAME            = "MC_Phase_1"
INSTRUMENT_NAME               = "Observatoire Mineralogie, Eau, Glaces, Activite"
INSTRUMENT_ID                 = OMEGA
TARGET_TYPE                   = PLANET
TARGET_NAME                   = MARS
START_TIME                    = 2004-01-14T00:19:12.032
STOP_TIME                     = 2004-01-14T00:23:03.059
SPACECRAFT_CLOCK_START_COUNT  = "22054009.23265"
SPACECRAFT_CLOCK_STOP_COUNT   = "22054240.00630"

/* DESCRIPTIVE DATA ELEMENTS */
ORBIT_NUMBER                  = 18
SPACECRAFT_POINTING_MODE      = "INERT"
SPACECRAFT_POINTING_MODE_DESC = "PSA to provide a description of spacecraft pointing modes"
SPACECRAFT_ORIENTATION        = (0,-1,0)
SPACECRAFT_ORIENTATION_DESC   = "PSA to provide a description of spacecraft orientations"
MAXIMUM_LATITUDE              = -63.879
MINIMUM_LATITUDE              = -64.568
EASTERNMOST_LONGITUDE         = 322.320
WESTERNMOST_LONGITUDE         = 318.376
SLANT_DISTANCE                = 1256.56
SOLAR_LONGITUDE               = 333.1
SOLAR_DISTANCE                = 223057848.34
SUB_SOLAR_LONGITUDE           = 297.553
SUB_SOLAR_LATITUDE            = -11.118
^DATA_DESC                    = "GEOCUBE_DESC.TXT"
DATA_QUALITY_ID               = "NULL"
SOFTWARE_NAME                 = "GEOMEG V4 / 2"
SPICE_FILE_NAME               = "ATNM_P030602191822_00087.BC,
                                 ORMM__031222180906_00052.BSP,
                                 MEX_040730_STEP.TSC,
                                 MEX_OMEGA_V04.TI,
                                 MEX_V05.TF,
                                 DE405S.BSP,
                                 MAR033_2000-2025.BSP,
                                 MARS_IAU2000_v0.TPC,
                                 NAIF0007.TLS"

/* DATA OBJECT DEFINITIONS */
OBJECT                        = QUBE
  AXES                        = 3
  AXIS_NAME                   = (SAMPLE,BAND,LINE)
  CORE_ITEMS                  = (64,51,31)
  CORE_ITEM_BYTES             = 4
  CORE_ITEM_TYPE              = LSB_SIGNED_INTEGER
  CORE_BASE                   = 0.0
  CORE_MULTIPLIER             = 1.0
  SUFFIX_BYTES                = 4
  SUFFIX_ITEMS                = (0,0,0)
  CORE_VALID_MINIMUM          = "NULL"
  CORE_NULL                   = "NULL"
  CORE_LOW_REPR_SATURATION    = -2147483648
  CORE_LOW_INSTR_SATURATION   = -2147483648
  CORE_HIGH_REPR_SATURATION   =  2147483647
  CORE_HIGH_INSTR_SATURATION  =  2147483647
  CORE_NAME                   = "RAW DATA NUMBER"
  CORE_UNIT                   = DIMENSIONLESS
END_OBJECT                    = QUBE

END/* LABEL STANDARDS */
PDS_VERSION_ID               = 3
LABEL_REVISION_NOTE          = "2004-04-10, YL-NM"

/* FILE CHARACTERISTICS */
RECORD_TYPE                  = FIXED_LENGTH
RECORD_BYTES                 = 512
FILE_RECORDS                 = 20668  
LABEL_RECORDS                = 7 
FILE_NAME                    = "ORB0103_1.PRE"

/* DATA OBJECT POINTER /*
^QUBE                        = 8

/* IDENTIFICATION DATA ELEMENTS */
DATA_SET_ID                  = "MEX-M-OMEGA-2-EDR-0000-0010-V1.0"
PRODUCT_ID                   = "ORB0103_1.PRE"
PRODUCT_TYPE                 = EDR
PRODUCT_CREATION_TIME        = 2004-04-01T23:04:03.00
PRODUCER_INSTITUTION_NAME    = IAS
PI_PDS_USER_ID               = BIBRING
SPACECRAFT_NAME              = "MARS EXPRESS"
MISSION_PHASE_NAME           = "NOMINAL"
INSTRUMENT_NAME              = "Observatoire Mineralogie, Eau, Glaces, Activite"
INSTRUMENT_ID                = OMEGA
TARGET_TYPE                  = PLANET
TARGET_NAME                  = MARS
START_TIME                   = 2004-02-11T16:41:12.43
STOP_TIME                    = 2004-02-11T16:49:52.43
SPACECRAFT_CLOCK_START_COUNT = 24597665.48500
SPACECRAFT_CLOCK_STOP_COUNT  = 24598185.48500

/* DESCRIPTIVE DATA ELEMENTS */
ORBIT_NUMBER                 = 103
SC_POINTING_MODE             = NADIR
SC_ORIENTATION               = BACKWARD
MAXIMUM_LATITUDE             = -77.795
MINIMUM_LATITUDE             = -88.712
EASTERNMOST_LONGITUDE        = 328.066
WESTERNMOST_LONGITUDE        = 164.955
SLANT_DISTANCE               = 1676.04
SOLAR_LONGITUDE              = 348.3
SOLAR_DISTANCE               = 228659086.36
SUB_SOLAR_LONGITUDE          = 326.408
SUB_SOLAR_LATITUDE           = -4.949
^DATA_DESC                   = "GEOCUBE_DESC.TXT"
DATA_QUALITY_ID              = "NULL"
SOFTWARE_NAME                = "GEOMEG V1 / 0"
SPICE_FILE_NAME              = "ATNM_P030602191822_00065.BC,
                                ORMM__040201000000_00060.BSP,
                                MEX_040220_STEP.TSC,
                                MEX_OMEGA_V04.TI,
                                MEX_V05.TF,
                                DE405S.BSP,
                                MAR033_2000-2025.BSP,
                                MARS_IAU2000_v0.TPC,
                                NAIF0007.TLS"

/* DATA OBJECT DEFINITIONS */
OBJECT                       = QUBE
  AXES                       = 3
  AXIS_NAME                  = (SAMPLE,BAND,LINE)
  CORE_ITEMS                 = (128,51,648)
  CORE_ITEM_BYTES            = 4
  CORE_ITEM_TYPE             = LSB_SIGNED_INTEGER
  CORE_BASE                  = 0.0
  CORE_MULTIPLIER            = 1.0
  SUFFIX_BYTES               = 4
  SUFFIX_ITEMS               = (0,0,0)
  CORE_VALID_MINIMUM         = "NULL"
  CORE_NULL                  = "NULL"
  CORE_LOW_REPR_SATURATION   = -2147483648
  CORE_LOW_INSTR_SATURATION  = -2147483648
  CORE_HIGH_REPR_SATURATION  =  2147483647
  CORE_HIGH_INSTR_SATURATION =  2147483647
  CORE_NAME                  = RAW_DATA_NUMBER
  CORE_UNIT                  = DIMENSIONLESS
END_OBJECT                   = QUBE

END


8 
Appendix D: PDS Glossary
		[ add your chapters as needed]etector B data level Y
4.6.2.1 File Characteristics Data Elements
4.6.2.2 Data Object Pointers Identification Data Elements
4.6.2.3 Instrument and Detector Descriptive Data Elements
4.6.2.4 Structure Definition of Instrument Parameter Objects 
4.6.2.5 Data Object Definition
4.6.2.6 Description of Instrument 
4.6.2.7 Parameters Index File Definition
4.6.2.8 Mission Specific Keywords


Appendix: Available Software to read PDS files
Appendix: AuxilliaryAuxiliary Data Usage


Archive – An archive consists of one or more data sets along with all the documentation and ancillary information needed to understand and use the data. An archive is a logical construct independent of the medium on which it is stored. 
Archive Volume, Archive Volume Set – A volume is a unit of media on which data products are stored; for example, one CD-ROM or DVD-ROM. An archive volume is a volume containing all or part of an archive; that is, data products plus documentation and ancillary files. When an archive spans multiple volumes, they are called an archive volume set. Usually the documentation and some ancillary files are repeated on each volume of the set, so that a single volume can be used alone.  
Catalog Information – Descriptive information about a data set (e.g. mission description, spacecraft description, instrument description), expressed in Object Description Language (ODL), which is suitable for loading into a PDS catalog.
Data Product – A labeled grouping of data resulting from a scientific observation, usually stored in one file. A product label identifies, describes, and defines the structure of the data. An example of a data product is a planetary image, a spectrum table, or a time series table.
Data Set – An accumulation of data products. A data set together with supporting documentation and ancillary files is an archive.






Appendix: Example of Directory Listing of Data Set X


??



 

 

8


?

Experiment Archive
Interface Control Document ROSETTATemplate for ‘EAICD’
To Planetary Science Archive Interface Control Document
Document No.
Document No.Issue/Rev. 
:  
:  OME-DU-061-214[RO-UoB-IF-1234]SOP-RSSD-TN-017
:  


Issue/Rev. No.
:  Draft 6.1:  5 NovemberOctober 2002


Date Date
:  01/05/200523/11/2004


Page 
:  41X
:  3Page



	


	

8



	ESOC European Space Operations Centre