VIRTIS Rosetta geometry files VIR-LES-TN-2338 Version 1.0 Prepared by S. Erard 23/03/2016 S. Jacquinod C. Leyrat X. Bonnin Checked by F. Capaccioni Approved by Authorized by TABLE OF CONTENTS - DOCUMENT CHANGE RECORD. 1- Introduction. 1.1 Applicable / Reference Documents. 1.2 Acronyms and Abbreviations. 2- Detailed specifications. 2.1 Data file labels. 2.2 Geometry files contents. 2.2.1 Reference surfaces. 2.2.2 Observations intercepting the surface. 2.2.3 Limb observations and other geometries. 2.3 Geometry file labels. Appendix-A FOV definitions. Appendix-B Code history. 1- Introduction This document defines the format and contents of the VIRTIS Rosetta geometry files for both M and H channels during the asteroids, Mars, and Earth flybys, and early phases of 67P observations. These files are distributed to the science team, and are part of the archive delivered to PSA. 1.1 Applicable / Reference Documents - AD1: EAICD Virtis Rosetta, VIR-INAF-IC-007, Issue 4.1 (24/3/2014) - AD2: VIRTIS PDS/IDL software library VVX-LES-SW-2264, Issue 3.1 (19/6/2013) - AD3: Rosetta Payload Boresight Alignment Details. RO-EST-TN-3305. Issue 2, rev. g (21 July 2014). + Spice kernels provided by ESA (IK and FK). - RD1: Seidelman et al., Report of the IAU/IAG working group on cartographic coordinates and rotational elements: 2006. Celestial Mechanics and Dynamical Astronomy 98: 155-180, 2007. - RD2: Smith, D., G. Neumann, R. E. Arvidson, E. A. Guinness and S. Slavney, "Mars Global Surveyor Laser Altimeter Mission Experiment Gridded Data Record", NASA Planetary Data System, MGS-M-MOLA-5-MEGDR-L3-V1.0, 2003. - RD3: Hastings, David A., Paula K. Dunbar, Gerald M. Elphingstone, Mark Bootz, Hiroshi Murakami, Hiroshi Maruyama, Hiroshi Masaharu, Peter Holland, John Payne, Nevin A. Bryant, Thomas L. Logan, J.-P. Muller, Gunter Schreier, and John S. MacDonald, 1999. The Global Land One-kilometer Base Elevation (GLOBE) Digital Elevation Model, Version 1.0. NOAA, National Geophysical Data Center (http://www.ngdc.noaa.gov/mgg/topo/globe.html). - RD4: Zuber, M. T., CLEM1 LUNAR TOPOGRAPHY V1.0, CLEM1-L-LIDAR-5-TOPO-V1.0, NASA Planetary Data System, 1996. - RD5: Jorda et al., ROS_STEINS_V04.TPC, January 2009 (Steins PCK from Osiris team) - RD6: Jorda et al., SteinsFinal.dsk, 2009 (Steins DSK from Osiris team) - RD7: Osiris pointing position relative to other boresights on Rosetta, RO-RIS-MPAE-TN-051, Issue 1.0, Rev. d (18 Jan 2008). - RD8: Archinal et al., Report of the IAU/IAG working group on cartographic coordinates and rotational elements: 2009. Celestial Mechanics and Dynamical Astronomy 109: 101-135, 2011. - RD9: Tosi et al., ROS_LUTETIA_RSOC_V03.TPC, Oct 2011 (Attitude kernel reconstructed from Osiris images, for Lutetia Closest Approach) - RD10: Kamp et al., lutetia_gaskell_mikko_v4-sbd1.ver, Oct 2011 (Lutetia DSK from Osiris images) - RD11: Scholten et al., Reference frames and mapping schemes of comet 67P - v2 (25 Sept. 2015) 1.2 Acronyms and Abbreviations EDR: Experimental Data Record EGSE: Electrical Ground Support Equipment FPA: Focal Plane Arrays DTM : Digital Terrain Model DSK : Digital Shape Kernel HK: HouseKeeping parameters IDL: Interactive Data Language IR: InfraRed ME: Main Electronic MSB: Most Significant Byte first OBT: On-Board Time PCK : Planetary Constants Kernel PDS: Planetary Data System PSA: Planetary Science Archive RDR: Reduced Data Record SCET: SpaceCraft Elapsed Time (on-board time measured in s from launch) SI: Systeme International de unites SPICE : Spacecraft Planet Instrument C-matrix Events TM: Telemetry UTC: Universal Time Corrected VIRTIS: Visible Infra Red Thermal Imaging Spectrometer 2- Detailed specifications The VIRTIS/Rosetta data archive contains geometrical information together with the data at various processing levels. This includes: 1) General/averaged information contained in the PDS label of data files, pertaining to the overall session. 2) Detailed information on a pixel basis, required to plot the data and to analyze them in details. This information is stored in separated geometry files associated to the data files. The detailed information is stored in separate files, so as to decouple maintenance of the data on one hand, and of the geometry on the other hand. Practically, the geometry files have to be generated several times, as navigation Spice kernels are updated by ESA. This scheme also preserves the possibility to generate and maintain calibrated/derived data files easily. Consequently, there is one geometry file associated to each data file. This implies that the geometry files are relevant to one focal plane only (separated files for H, M-vis, M-IR). When processing a data file, only the corresponding geometry file needs to be loaded. Geometry information in the data files labels is computed and implemented in Rome through the SPICE system. Detailed geometry computations are later performed by a specific IDL library developed and maintained in Meudon (GeoRos), relying on the Spice toolkit for IDL (ICY, version N0065 from July 2014). The types of information are described in the next sections. A "geometric index" file was initially required by ESA specifications, together with a description of each data file. This specification appears to be deprecated and therefore this discussion has been removed from the present document. 2.1 Data file labels Data file labels are described in the current versions of the EAICD [AD 1], and derived documents. These geometric quantities are computed with the SPICE system then included in the PDS labels of the data files written by the EGSE. This means that the raw data files are written in two steps: 1) Formatting in EGSE, with attached PDS labels. The geometrical keywords have dummy values (such as "NULL"). 2) Computation of geometrical quantities with the SPICE system, outside the EGSE. Files generated in the first step are edited and completed with the proper values for the geometric keywords, derived from SPICE analysis. This activity is performed in Rome. It also covers general keywords such as target identification, the values of which are derived from science planning. This information is also stored in the database in Meudon once for all, so that keyword values may be updated in later stages. The updated data files are distributed to the science team. The calibrated or derived data files are written from these versions, with complete labels that include values associated to the geometrical keywords. There are currently two versions of the geometry files generated in Meudon. - Version 6 files (with extension .GEO) contain a standard number of parameters allowing a correct interpretation of the data. This is based on 67P shape model 5, which is partly outdated. - Version 7 files are an extended version of the same files with additional planes as described below. 2.2 Geometry files contents The Virtis/Rosetta geometry files for the three focal planes are written by the GEOROS software developed in Meudon. This system makes use of the SPICE kernels distributed by ESA, of Virtis-M CK kernels computed in Rome to handle the scanning mirror angle, and when relevant of target DSK kernels providing a plate model. M CK kernels are generated after observations from TM information, and reflect what has actually been done. As mentioned above, geometry is computed and stored independently for each FPA. Virtis geometry files contain a cube with structure related to the data file, so that there is a direct correspondence between the two: - Raw data cube dimensions = (X, Y, Z), where X is the number of spectral channels. X and Y depend on instrumental mode, and Z depends on session duration. The sideplane contains the housekeeping parameters. - Calibrated data cubes dimensions = (X, Y'', Z''). A small side plane is associated, containing only the spacecraft time (SCET) of acquisition. - Geometry cube dimensions = (N, Y', Z'), where N is the # of geometrical parameters for this FPA/channel. There is no sideplane associated to the cube core. - For M cubes, Z'=Z'' is equal to the number of spectral frames in the data cube, while Z is equal to the number of spectral frames + dark current frames. The same applies to H cubes in backup (frame transfer) mode. In H nominal mode however, dark frames are stored independently. - M geometry cubes always have Y' = Y (value depends on binning mode). - For H in backup mode, X = 432 and Y = 256 (detector size), whereas Y'=Y''= 1 (each data frame contains a detector image, but is described by 1 single geometry column). - H cubes in nominal mode always have Y = Y'= 64 and Z = Z' is the number of 64-spectra sets. Y'' = Y x Z, and X'' = 1 (therefore the second dimension is always degenerated, and the spectra are stored in chronologic order with their associated SCET - the raw data files dimensions are maintained for the geometry files which have no associated sideplane). Geometry files for M and H channels have different parameters, reflecting their different acquisition scheme and optical design. Geometry files for 67P contain more parameters than for other targets, owing to the shape of the comet nucleus. The geometry cubes are stored as long signed integers with MSB encoding. A simple conversion coefficient is used to accommodate the data in this format, so as to preserve accuracy (see below). The geometry files are handled directly by the VIRTIS IDL library and its front-end routine virtispds [AD 2]. 2.2.1 Reference surfaces For observations of the target bodies, each observed pixel is projected successively at the surface, and the coordinates of the IFOV corners and center are written in the geometry files. During computations, two projection surfaces are used (ellipsoid and Digital Terrain Model when available). Successive Rosetta targets are handled differently, but during the cruise phase only the coordinates projected on the DTM are written in the geometry files. Practically, the differences are almost unnoticeable, except for the asteroids. The reference frames used in the archive are listed in Table 1, together with their definition kernels (maintained by the PSA and NAIF, and distributed by ESA). Venus and Jupiter have been observed as calibration targets only. |--------------------|----------------------|-----------------------|-------| |COORDINATE_SYSTEM_ID|COORDINATE_SYSTEM_NAME| Kernel | Target| |--------------------|----------------------|-----------------------|-------| |10012 | IAU_VENUS |Generic spice kernels |Venus | |10013 | IAU_EARTH |Generic spice kernels |Earth | |10020 | IAU_MOON |Generic spice kernels |Moon | |10014 | IAU_MARS |Generic spice kernels |Mars | |10015 | IAU_JUPITER |Generic spice kernels |Jupiter| |2002867 | STEINS_FIXED |ROS_V25.TF |Steins | |-2260021 | ROS_LUTETIA |ROS_LUTETIA_RSOC_V03.TF|Lutetia| |-1000012000 | 67P/C-G_CK |ROS_CHURYUMOV_V01.TF |67P | |--------------------|----------------------|-----------------------|-------| Table 1: Body-fixed reference frames in use for solar system bodies Mars 2007 swing-by (MSB) The projection surfaces used for Mars observations during the 2007 swing-by (MSB) are: 1) The Mars reference ellipsoid defined in IAU 2006 standard [RD1, RD8]. This surface is the one described in generic SPICE kernels. 2) The Mars DTM measured by MOLA [RD2]. Only the 32 pixels/degree version is used for VIRTIS. The estimated accuracy on the pointing direction is ~0.02 deg. Earth swing-bys (ESB1/2/3) A similar system is used for the observations of the Earth and the Moon during the 2005, 2007 and 2009 swing-bys (ESB1, ESB2, ESB3). The projection surfaces used are: 1) The Earth and Moon reference ellipsoid defined in the IAU 2006 standard (see [RD1, RD8]). Those are provided in generic SPICE kernels. 2) The Earth DTM measured by GLOBE [RD3] and the Moon DTM measured by the LIDAR instrument onboard the Clementine spacecraft [RD4]. The resolutions of the Earth and Moon DTM used for the Rosetta swing-bys are respectively 32 pixels/degree and 4 pixels/degree. Steins fly-by (AFB1) For the observations of the asteroid Steins during the 2008 fly-by, the projection surfaces used are: 1) The Steins reference ellipsoid updated from OSIRIS observations during the Rosetta fly-by. The corresponding SPICE PCK file is provided by the OSIRIS team and distributed by ESA: ROS_STEINS_V04.TPC [RD5]. 2) The Steins 3D plate model derived from OSIRIS observations during the Rosetta fly-by. This model is also provided by the OSIRIS team as a Digital Shape Kernel (DSK) SPICE file: SteinsFinal.dsk [RD6]. The VIRTIS Spice computation uses an attitude kernel reconstructed to fit successive Osiris images, which is now distributed by ESA. According to IAU conventions, the polar axis in this model is oriented along the spin axis of the asteroid. Because Steins has a retrograde rotation, this implies that the North Pole actually points in the southern celestial hemisphere at the time of the fly-by. Lutetia fly-by (AFB2) For the observations of the asteroid Lutetia during the 2010 fly-by, the projection surfaces used are: 1) The Lutetia reference ellipsoid updated from OSIRIS observations during the Rosetta fly-by. The corresponding SPICE PCK file is provided by the OSIRIS team and distributed by ESA: ROS_LUTETIA_RSOC_V03.TPC [RD9]. 2) The Lutetia 3D plate model derived from OSIRIS observations during the Rosetta fly-by. We use a model provided by Lucas Kamp (from the MIRO team), which is then transformed into a Digital Shape Kernel (DSK) SPICE file: lutetia_gaskell_mikko_v4-sbd1.dsk [RD10]. The VIRTIS Spice computation uses an attitude kernel reconstructed to fit successive Osiris images. This kernel is now distributed by ESA. In addition, the BODY_FRAME variable is set to ROS_LUTETIA instead of LUTETIA_FIXED. 67P observations For the observations of 67P after June 2014 (prelanding and escort phases), the projection surfaces used are: 1) A reference ellipsoid for 67P. 2) A 3D shape model of the nucleus. Both are associated to Spice kernels for comet rotation and prime meridian, and for comet trajectory. Several shape models have been used in succession. The shape model in use, as well as the other Spice kernels, can be identified from the SPICE_FILE_NAME keyword in the PDS labels (Table 2). Ellipsoid dimensions were included in the rotation kernel by LESIA, and may change between shape models. - The Osiris shape model 7 SPC (SHAP7 v1.8, as distributed by the Osiris team and included in the Rosetta shape model archive) is the baseline for the final dataset and archive. This shape model provides improved topography in the southern hemisphere with respect to the previously used shape 5. The zero longitude in this model is aligned with the RMOC comet attitude file, and both use the so-called "Cheops" frame defined by the Osiris team [RD11] as described in Table 2. The precession and variation of the nucleus rotation rate are included in the CATT kernels provided by ESA, to the level where they can be detected with the Navcam. "Extended geometry" files were produced based on shape model 7 starting June 2017 (*.GE7 files). All observations were reprocessed and distributed to the team in addition to the standard ones, and proved to be the most accurate and convenient ones. Cartesian coordinates are included in the extended geometry files to remove any ambiguity on longitude/latitude resulting from the concave shape of the nucleus. Other shape models have been used prior to June 2019, but the corresponding geometry files have normally been superseded and are not expected to circulate outside the VIRTIS team: - Shape model 1 from OSIRIS observations acquired in July 2014. This is the 500 m resolution model (SHAP1 v3, as collected and distributed by CNES/SONC), which is then transformed into a Digital Shape Kernel (DSK) SPICE file. - Osiris shape model 2 (SHAP2 v1 with 20 m resolution, as collected and distributed by CNES/SONC). This one was used in the pre-landing phase from mid-August 2014, and up to January 2015. - Osiris shape model 5 v0.1 with full resolution was used from January 2015 to February 2016. Although using the Cheops frame and aligned with RMOC attitude files, this shape model was very inaccurate in the southern hemisphere that had only been sparsely observed at that time. This was associated to a rotational kernel, which was completed in LESIA based on early information provided by the Osiris team: cg-spc- shap5-v0.1_SJmodified.TPC. The shape model resolution was ~ 20 m in the northern hemisphere. - Osiris shape model 5 (SHAP5 v1.1, as distributed by the Osiris team) with full resolution was used from February 2016 to June 2019 (completed with shape model 7 from June 2017). All observations have been reprocessed using this shape model in February 2016, including older ones. The zero longitude in this model is aligned with the RMOC comet attitude file, and both use the so-called "Cheops" frame defined by the Osiris team [RD11] as described in Table 2. It is associated to a rotational kernel, which was completed in LESIA based on information provided by the Osiris team: cg-spc-shap5-v1.1_Cedric.TPC. The precession and variation of the nucleus rotation rate are included in the CATT kernels provided by ESA, to the level where they can be detected with the Navcam. The shape model resolution is ~20 m, including in the southern hemisphere. "Extended geometry" files based on shape model 5 were produced from July 2016 and distributed to the team in addition to the standard ones (*.GE5 files). They include in particular coordinates in a Cartesian frame, so as to remove any ambiguity on longitude/latitude resulting from the concave shape of the nucleus. Other shape models were tested at some points but were found to have issues: - The RMOC model, with limited resolution, was temporarily used in August 2014. - Osiris shape model 4 (SHAP4 v1.1, as distributed by the Osiris team) with 800 000 facets, had issues related to nucleus orientation. This was associated to: - coordinate system ID (SPICE system ID) = "1000012" - coordinate system name = "67P/C-G_FIXED" In this situation, the RMOC kernels (trajectory / attitude) and the Osiris shape model may have been poorly consistent. The above ID and name were temporary used with SHAP5 (up to 10/5/2015) - the corresponding files were not properly corrected from variations of rotation rate and have been discarded. The final geometry cubes are computed using the reconstructed comet positioning provided by ESA one or two weeks after observation. A first version (*.PRE) is computed as the data become available, based on the predicted pointing; when visible, the target limb is often shifted in the FoV by a large amount (tens of M pixels), consistently with the expected pointing accuracy. When a reconstructed version becomes available the regular files are computed and are named *.GEO; the remaining shift is typically less than 5 VIRTIS-M pixels (0.07 deg ca), and often better. New versions may be computed if the reconstruction is further improved in successive kernels. The accuracy of the projection is limited by the knowledge of the nucleus location and orientation. Owing to the accuracy of the NAC frame and its internal deformations, a conservative estimate is 3 VIRTIS-M pixels. The accuracy of the retrieved longitudes and latitudes, related to the resolution of the shape model, is on the order of 0.05 deg (i.e., round-off issues may result in errors with this order of magnitude). Geometry aberrations at the borders of the field of view of the M channels and wavelength-dependent pointing offsets for both M and H channels have been identified; they amount to the same order of magnitude. |-----------|-------------------------|--------------------------|------------| |Shape model|Shape model file |Associated rotation kernel|Radii of | | | | | associated | | | | |ellipsoid, | | | | | km | |-----------|-------------------------|--------------------------|------------| |SHAP1 v3 |RS_GLOBAL_DTM_500m_ |RS_ROT_PARAM_500m_ | 2.2 | | | SHAP1v3.bds | SJmodified.TPC | 1.75 1.25 | |-----------|-------------------------|--------------------------|------------| |SHAP2 v1 |RS_GLOBAL_DTM_20m_ |RS_ROT_PARAM_20m_ | 2.446029 | | | SHAP2v1.bds | SJmodified.TPC | 1.565140 | | | | | 1.389072 | |-----------|-------------------------|--------------------------|------------| |SHAP5 v0.1 |cg-spc-shap5-v0.1 |cg-spc-shap5-v0.1_ | 2.2 | | | -esoc.bds | SJmodified.TPC+ | 1.75 | | | | ROS_V24.TF | 1.25 | |-----------|-------------------------|--------------------------|------------| |SHAP5 v1.1 |cg-spc-shap5-v1.1 |cg-spc-shap5-v1.1_ | 2.446 | | | -cheops.bds | Cedric.TPC + | 1.565 | | | | ROS_V25.TF | 1.389 | |-----------|-------------------------|--------------------------|------------| |SHAP7 SPC |cg-spc-shap7-v1.8-cheops |ROS_CG_ROT_1408_1409 | 2.40 | | v1.8 |_24-05-2017.bds |_V10.TPC + ROS_V27.TF | 1.55 | | | | | 1.20 | | | | |- from | | | | |ROS_CG_RAD_ | | | | |V10.TPC | |-----------|-------------------------|--------------------------|------------| Table 2: Shape models information for 67P 2.2.2 Observations intercepting the surface The geometry cube planes are listed in Table 3 and illustrated in Fig. 2. The description below applies to the Earth, Moon, Mars, asteroid flybys and 67P observations with the corresponding topographic models (i.e. DTM or shape model). All computations are performed in the planetocentric system (i.e., relative to the local vertical) and using eastward longitudes. The geographic frames are those implemented in the SPICE kernels, and defined in the IAU 2006 system [RD1, RD8]. The coordinates of the four pixel footprint corners and of the pixel central point are computed at the intersection of the line of sight with the DTM or shape model. For Mars observations, at such low resolution the with a projection on the areoid is significant only on large volcanoes and basins/canyons, or at large emergence angles. The same stands for the Earth and the Moon. However the difference is significant in the case of Steins, Lutetia and 67P. Surface elevation is the value from the DTM or shape model, provided as the altitude above the reference ellipsoid (i.e., shape model radius - ellipsoid radius). It is provided at the pixel center; whenever the pixel center value is missing, a special error code is recorded in the file (the value -20,000 m is used; it is negative and lower than the minimal elevation on Mars). The other quantities are also computed at the pixel center. The three observing angles (incidence, emergence, phase) are provided in 3 systems: on the DTM (relative to local normal), with respect to the direction of the center of target (center of figure), and relative to the ellipsoid normal. The first set of values is related to surface photometry/shadows, the second one to the airmass. The spacecraft slant distance is computed from the surface ellipsoid (not including the topography). Local time is measured from local midnight. Right ascension and declination of the line of sight are computed for each pixel in all observing modes. Other instrument-related information is stored in the geometry cubes, including SCET, UTC, and scanning mirror angle for M. SCET are copied directly from the data files, except in the case of H nominal mode where they are reconstructed for each spectrum from acquisition parameters. UTC are the corresponding values recomputed from the SPICE kernels (not using the DDS approximation provided through the EGSE), then translated at mid-exposure (the offset is equal to half the repetition time). UTC is stored on two words, the first one providing the number of day since Jan. 1st, 2000 (starting at 1), the second one providing 10,000 x the number of s on this day, starting at 0h. For H, the slit orientation is provided as the angle between the ellipsoid normal and the longest slit direction (in the plan orthogonal to the line of sight, see Figure 3). For M, the mirror angle is stored as the sine and cosine of this angle (HK parameters are decoded using the adequate transfer function). Whenever these codes are missing in the TM, they are reconstructed using the same algorithm as in the Main Electronics (this may occur for M-IR paquets with no corresponding M-vis paquet). Finally, the Sun direction is provided as the angle from the instrument boresight and its azimuth in the XY plane, counted from the X axis (Figure 4). (note: these two parameters have been modified in June 2015 with georos v7). For H, all quantities are computed on a pixel basis. For M, those which are common to a complete frame are stored in the same plane; they comprise SCET, UTC, sub-S/C coordinates, mirror angle and Sun-boresight direction in the orthogonal plane (10 words, whereas the minimum plane dimension is 64). All parameters are stored on 4 bytes as long signed integers (Table 4). Angles (coordinates, viewing angles, and alpha/delta) are stored in degrees and multiplied by 10,000. Distances are stored in meters. Sine and cosine of mirror angle are multiplied by 1000. Local time is stored in units of the target period/24 (local hours) multiplied by 100,000. Parameters based on data or HK which are absent from the TM are replaced by the value - 2147483648 ('80000000' hexa; this actually occurs mainly for mirror angle parameters). Geometric information that can be considered constant in the time frame of one subsession is also stored in the label of the geometry files, including sub-solar point coordinates at the surface, solar distance, and solar longitude. Solar longitude is computed as the planetocentric longitude of the Sun (Ls), starting from body's North hemisphere spring equinox. Regular geometry files provided for secondary targets (.GEO) contain 23 planes for M and 31 for H. Extended geometry files (.GE7) contain 100 planes for M and 112 for H and are provided only for 67P. Plane 22 in M files provides quantities common to all pixels acquired at a given time step (along the slit). Planes 22-34 in H files contain parameters specific to the H channel. Table 1 provides plane numbers for M and H as written in the files. Note that when reading them with the virtispds routine, the plane numbers from H are used for both channels and M planes 23-34 are empty. This allows using the same extended geometry plane numbers for both channels. FIGURE07 |-------------|-----------------------------|----------------------------------| |Quantity | Unit |Comment | |-------------|-----------------------------|----------------------------------| |Angles |Degrees * 10,000 | | |-------------|-----------------------------|----------------------------------| |Distances |m | | |-------------|-----------------------------|----------------------------------| |Sine / cosine|Value * 1000 |M scanning mirror only | |-------------|-----------------------------|----------------------------------| |Local time |Period/24 * 100,000 |Period from rotation kernel, from | | | | midnight | |-------------|-----------------------------|----------------------------------| |(all) |-2147483648 = '80000000' hexa|Missing HK parameter | |-------------|-----------------------------|----------------------------------| |Elevation |+100,000 |Offset added to non-intercepting | | | |lines of sight (see section 2.2.3)| |-------------|-----------------------------|----------------------------------| |Elevation |-20,000 |Missing value at pixel center | |-------------|-----------------------------|----------------------------------| Table 4: Encoding and special values used in geometry files Binary flags in frame 83 (for M) or 95 (for H) provide detailed information about illumination conditions. After conversion to LSB order (Intel platforms), the flags are encoded on the first 2 bytes and look like in the table below. Flags can be printed under IDL with: im.qube(95,i), format='(B16.16)' Individual bits can be tested under IDL with AND and OR operators (see FIGURE08). The shadow and visibility flags are ordered as [corner1-4, center]. Shadow flags are set to 0 if the point is not illuminated or in the coma. Visibility flags are set to 0 if the point is hidden from the observer or in the coma; this is intended to identify pixels straddling the limb, or pixels partly masked by other facets. However, this relies on a Spice routine in beta version, and inconsistent information may be returned very close to the limbs (e. g., shadow flag set to 1 and visibility flag set to 0); these pixels usually have an emergence angle > 90 deg. The suggested practice is to use the shadow flags to identify illumination conditions: (im.qube(83,128,30) and '0000001111100000'b) EQ 1 ; true if entirely illuminated and to use the last planes to check if the FoV corners intercept the nucleus: product(geomm.Qube(95:99,128,30)) NE -999 ; true if entirely on nucleus FIGURE02: Observations intercepting the surface for planets, the reference ellipsoid is in general inside the DTM) FIGURE03: Slit orientation for Virtis-H FIGURE04: Sun direction in the instrument frame 2.2.3 Limb observations and other geometries Whenever the line of sight does not intercept the surface, the above quantities are replaced by specific information (FIGURE05).The tangent point is always defined as the point along the line of sight that is closest to the surface of the target. For planets, this is also the point closest to the target center. On 67P, because of target concavity the tangent point is computed along the line of sight to search for the minimum distance to the shape model; a secondary maximum may be present on the other lobe, and is not documented in the files. Note: as of writing, defining the tangent point this way is prohibitive in terms of computing time for 67P. For the time being, the tangent point on 67P observations is therefore defined as the closest point to the ellipsoid. This may be improved in the future. - During limb observations surface elevation (plane 18) is replaced by the tangent altitude (impact parameter above the surface, counted from the shape model or DTM) with the addition of a large offset (100,000 m, see Table 4). This offset is intended to select or filter limb observations easily. The 100,000 m offset must be subtracted from plane 18 (counting from 1) to retrieve the tangent altitude. - Angles, local time, and slant distance are computed at the intersection with the vector passing through the center of the target (tangent point). - The H slit orientation cannot be retrieved from surface coordinates, but is available in plane 29 (counting from 1). The same system is used for sub-pixel targets (unresolved observations). In this case, the target is located inside the pixel displaying the shorter distance to the target (which is measured from pixel center). FIGURE05: Limb/coma observations 2.3 Geometry file labels An example of PDS label for the geometry cubes is given in Table 5 for Virtis-H. This is essentially a shortened version of the raw data files labels. Four new keywords provide extra geometric information not available in the data file labels: solar distance, season, and sub-solar point coordinates (lines in red in Table 5). Solar distance, solar longitude, and sub-solar point coordinates are computed at start of acquisition, and are about constant during a session. Slant distance is the average value encountered during observation. The other values are either minimum/maximum values (for coordinates) or start/stop values (for times). Four extra keywords are present in the Virtis-M geometry files. They are all related to the scanning mode, and are identical to those present in the data file labels. |--------------------|---|-----|-------------------|--------------------------| | Keyword |SSE|Type |Possible values |Description | | | | | / range | | |--------------------|---|-----|-------------------|--------------------------| |PDS_VERSION_ID | SC| ID | PDS3 |Version of PDS standard | | | | | |used, constant | |--------------------|---|-----|-------------------|--------------------------| |LABEL_REVISION_NOTE | SC| CHAR|SE-MTC, 7/06/2013 |ID of label version | |--------------------|---|-----|-------------------|--------------------------| |(blank line) | |--------------------|---|-----|-------------------|--------------------------| |/* File format and length */ | |--------------------|---|-----|-------------------|--------------------------| |PRODUCT_ID | SC| CHAR| "xxx.GEO" |Current file name with | | | | | |extension | |--------------------|---|-----|-------------------|--------------------------| |ORIGINAL_PRODUCT_ID | SC| CHAR| "xxx.QUB" |Original data file name | | | | | |with extension (ie: | | | | | |PI72P331.QUB) | |--------------------|---|-----|-------------------|--------------------------| |RECORD_TYPE | SC| ID | FIXED_LENGTH |File formatting info | |--------------------|---|-----|-------------------|--------------------------| |RECORD_BYTES | SC| INT | 512 |Record length in bytes, | | | | | |constant | |--------------------|---|-----|-------------------|--------------------------| |FILE_RECORDS | SC| INT | nn1 |Total file length / | | | | | |RECORD_BYTES (closest | | | |integer greater than or | | | |equal to this value) | |--------------------|---|-----|-------------------|--------------------------| |LABEL_RECORDS | SC| INT | 10 |Smallest integer large | | | | | |enough to accommodate the | | | | | |label up to the END | | | | | |keyword (ie., label length| | | | | |in byte lt LABEL_RECORDS *| | | | | |512) | |--------------------|---|-----|-------------------|--------------------------| |FILE_STATE | SC| ID | CLEAN |Flag for incomplete files,| | | | | |constant | |--------------------|---|-----|-------------------|--------------------------| |(blank line) | |--------------------|---|-----|-------------------|--------------------------| |/* Pointers to data objects | |--------------------|---|-----|-------------------|--------------------------| |*/ | |--------------------|---|-----|-------------------|--------------------------| |^QUBE | SC| PT | nn2 | LABEL_RECORDS + 1 | |--------------------|---|-----|-------------------|--------------------------| |(blank line) | |--------------------|---|-----|-------------------|--------------------------| |/* Producer information */ | |--------------------|---|-----|-------------------|--------------------------| |PRODUCER_ID | SC| CHAR|ROSETTA_VIRTIS_TEAM| (constant) | |--------------------|---|-----|-------------------|--------------------------| |PRODUCER_FULL_NAME | SC| CHAR| "CORADINI" | (constant) | |--------------------|---|-----|-------------------|--------------------------| |PRODUCER_INSTITUTION| SC| CHAR|"OBSERVATOIRE DE | (constant) | |_NAME | | | PARIS-LESIA" | | |--------------------|---|-----|-------------------|--------------------------| |PRODUCT_CREATION | SC| TIME|yyyy-mm-ddT |Time when the PDS file is | | _TIME | | | hh:mm:ss.fff | written | |--------------------|---|-----|-------------------|--------------------------| |TELEMETRY_SOURCE_ID | SC| CHAR|"VIRTIS_EGSE" |EGSE ID ( is the | | | | | |version number of EGSE | | | | | |itself = 3) | |--------------------|---|-----|-------------------|--------------------------| |SOFTWARE_VERSION_ID |SET| CHAR|{"VirtisROS SW |Versions ID of software | | | | | v.4.10", |used to process this file,| | | | |"EGSE_SOFT_", |including on-board | | | | |"PDS_CONVERTER_

"|software and conversion | | | | |"EGSE2PSA_CONVLABEL|routines. | | | | |_1.2.2", |,

and are the | | | | |"GEOROS_", |version numbers of EGSE | | | | |"V_GEOLABEL_6"} |and GEOROS software. | | | | | |v_geolabel is the software| | | | | |writing the files | |--------------------|---|-----|-------------------|--------------------------| |(blank line) | |--------------------|---|-----|-------------------|--------------------------| |/* Data description | |parameters */ | |--------------------|---|-----|-------------------|--------------------------| |DATA_SET_NAME | SC| CHAR|"xxx" |(Same as raw data) | |--------------------|---|-----|-------------------|--------------------------| |DATA_SET_ID | SC| CHAR|"xxx " |(Same as raw data) | |--------------------|---|-----|-------------------|--------------------------| |PRODUCT_TYPE | SC| ID |EDR |(constant) | |--------------------|---|-----|-------------------|--------------------------| |PROCESSING_LEVEL_ID | SC| INT |2 |As in DATA_SET_ID | |--------------------|---|-----|-------------------|--------------------------| |STANDARD_DATA | SC| CHAR|"VIRTIS GEOMETRY" |Identifies data versus | |_PRODUCT_ID | | | |geometry | |--------------------|---|-----|-------------------|--------------------------| |MISSION NAME | SC| CHAR|"INTERNATIONAL |(constant) | | | | |ROSETTA MISSION" | | |--------------------|---|-----|-------------------|--------------------------| |MISSION_ID | SC| ID |ROSETTA |(constant) | |--------------------|---|-----|-------------------|--------------------------| |INSTRUMENT_HOST_NAME| SC| ID |"ROSETTA-ORBITER" |(constant) | |--------------------|---|-----|-------------------|--------------------------| |INSTRUMENT_HOST_ID | SC| ID |RO |(constant) | |--------------------|---|-----|-------------------|--------------------------| |MISSION_PHASE_NAME | SC| CHAR|"xxx" |String, as defined by PSA | | | | | | MTP # for 67P | |--------------------|---|-----|-------------------|--------------------------| |PI_PDS_USER_ID | SC| CHAR|"CORADINI" |(constant) | |--------------------|---|-----|-------------------|--------------------------| |INSTRUMENT_NAME | SC| CHAR|"VISIBLE AND |(constant) | | | | |INFRARED THERMAL | | | | | |IMAGING | | | | | |SPECTROMETER" | | |--------------------|---|-----|-------------------|--------------------------| |INSTRUMENT_ID | SC| ID |"VIRTIS" |(constant) | |--------------------|---|-----|-------------------|--------------------------| |INSTRUMENT_TYPE | SC| CHAR|"IMAGING |(constant) | | | | |SPECTROMETER" | | |--------------------|---|-----|-------------------|--------------------------| |^INSTRUMENT_DESC | SC| PT |"RO_VIRTIS |(constant) | | | | | _EAICD.ASC" | | |--------------------|---|-----|-------------------|--------------------------| |ROSETTA:CHANNEL_ID | SC| ID |"VIRTIS_H" |(constant) | |--------------------|---|-----|-------------------|--------------------------| |DATA_QUALITY_ID | SC| INT |0 |0 if TM data paquets are | | | | |1 |missing when writing PDS | | | | |"NULL" |data 1 otherwise | | | | | |"NULL" is no diagnostic | | | | | |(may be used to store | | | | | | othererror codes) | |--------------------|---|-----|-------------------|--------------------------| |DATA_QUALITY_DESC | SC| CHAR|"0:INCOMPLETE ; |(constant) | | | | |1:COMPLETE" | | |--------------------|---|-----|-------------------|--------------------------| |(blank line) | |--------------------|---|-----|-------------------|--------------------------| |/* Science operations | |information */ | |--------------------|---|-----|-------------------|--------------------------| |TARGET_TYPE | SC| CHAR|"PLANET" |As defined by PSA | | | | |"CALIBRATION" | | | | | |"SKY" | | | | | |"ASTEROID" | | | | | |"COMET" | | |--------------------|---|-----|-------------------|--------------------------| |TARGET_NAME | SC| CHAR|"EARTH" |As defined by PSA | | | | |"MARS" | | | | | |"CALIBRATION" | | | | | |"SKY" | | | | | |"2867 STEINS" | | | | | |"21 LUTETIA" | | | | | |"67P/" | | |--------------------|---|-----|-------------------|--------------------------| |START_TIME | SC| TIME|yyyy-mm-dd |UTC of first acquisition | | | | |Thh:mm:ss.fff | | |--------------------|---|-----|-------------------|--------------------------| |STOP_TIME | SC| TIME|yyyy-mm-dd |UTC of last acquisition | | | | |Thh:mm:ss.fff | | |--------------------|---|-----|-------------------|--------------------------| |SPACECRAFT_CLOCK | SC| CHAR|"n/sssssssssss |Formatted, from TM packet | |_START_COUNT | | |.fffff" |data field header. | | | | | |n is increased after each | | | | | |resynchronization of the | | | | | |S/C clock, starting from 1| |--------------------|---|-----|-------------------|--------------------------| |SPACECRAFT_CLOCK | SC| CHAR|"n/sssssssssss |Formatted, from TM packet | |_STOP_COUNT | | |.fffff" |data field header. | | | | | |n is increased after each | | | | | |resynchronization of the | | | | | |S/C clock, starting from 1| |--------------------|---|-----|-------------------|--------------------------| |ORBIT_NUMBER | SC| INT|"N/A" |Reserved, unused during | | | | | |cruise | |--------------------|---|-----|-------------------|--------------------------| |OBSERVATION_TYPE | SC| CHAR|"xxx" |Reserved for future use | |--------------------|---|-----|-------------------|--------------------------| |SC_SUN_POSITION |VEC| REAL|(x,x,x) |Provides sun direction in | |_VECTOR | | | |J2000 frame | |--------------------|---|-----|-------------------|--------------------------| |SC_TARGET_POSITION |VEC| REAL|(x,x,x) |Provides target direction | |_VECTOR | | | |in J2000 frame | |--------------------|---|-----|-------------------|--------------------------| |SC_TARGET_VELOCITY |VEC| REAL|(x,x,x) |Provides target velocity | |_VECTOR | | | |in J2000 frame | |--------------------|---|-----|-------------------|--------------------------| |COORDINATE_SYSTEM_ID| SC| PT |"xxx" |Spice code of body-fixed | | | | | |reference frame in use | |--------------------|---|-----|-------------------|--------------------------| |COORDINATE_SYSTEM | SC| PT |"xxx" |Spice name of body-fixed | |_NAME | | | |reference frame in use | |--------------------|---|-----|-------------------|--------------------------| |DECLINATION | SC| REAL|0.0 |J2000 coordinate | |--------------------|---|-----|-------------------|--------------------------| |RIGHT_ASCENSION | SC| REAL|0.0 |J2000 coordinate | |--------------------|---|-----|-------------------|--------------------------| |MAXIMUM_LATITUDE | SC| REAL|000.000 |In decimal degrees | |--------------------|---|-----|-------------------|--------------------------| |MINIMUM_LATITUDE | SC| REAL|000.000 |In decimal degrees | |--------------------|---|-----|-------------------|--------------------------| |EASTERNMOST | SC| REAL|000.000 |In decimal degrees, | |_LONGITUDE | | | |Eastward longitudes | |--------------------|---|-----|-------------------|--------------------------| |WESTERNMOST | SC| REAL|000.000 |In decimal degrees, | |_LONGITUDE | | | |Eastward longitudes | |--------------------|---|-----|-------------------|--------------------------| |SPACECRAFT_ALTITUDE | SC| REAL|0000.000 |Average value in km | |--------------------|---|-----|-------------------|--------------------------| |PHASE_ANGLE | SC| REAL|0000.000 |In decimal degrees | |--------------------|---|-----|-------------------|--------------------------| |SUB_SPACECRAFT | SC| REAL|0000.000 |In decimal degrees | |_LATITUDE | | | | | |--------------------|---|-----|-------------------|--------------------------| |SUB_SPACECRAFT | SC| REAL|0000.000 |In decimal degrees, | |_LONGITUDE | | | |eastward | |--------------------|---|-----|-------------------|--------------------------| |SLANT_DISTANCE | SC| REAL|0000.000 |Average value in km | |--------------------|---|-----|-------------------|--------------------------| |SOLAR_DISTANCE | SC| REAL|0000.000 |Sun-target distance in km | |--------------------|---|-----|-------------------|--------------------------| |SOLAR_LONGITUDE | SC| REAL|0000.000 |Ls, counted from vernal | | | | | |equinox, in decimal | | | | | |degrees | |--------------------|---|-----|-------------------|--------------------------| |SUB_SOLAR_LONGITUDE | SC| REAL|0000.000 |Longitude of sub-solar | | | | | |point, in decimal degrees | |--------------------|---|-----|-------------------|--------------------------| |SUB_SOLAR_LATITUDE | SC| REAL|0000.000 |Latitude of sub-solar | | | | | |point, in decimal degrees | |--------------------|---|-----|-------------------|--------------------------| |NOTE | | |"bla-bla" |Information note requested| | | | | |bythe PSA, should not | | | | | |include "=" sign | |--------------------|---|-----|-------------------|--------------------------| |(blank line) | |--------------------|---|-----|-------------------|--------------------------| |/* Instrument status */ | (constant) | |--------------------|---|-----|-------------------|--------------------------| |INSTRUMENT_MODE_ID | SC| INT |1 H_Off |H channel functioning | | | | |2 H_Cool_Down |mode,M counterparts are | | | | |3 H_Idle |different | | | | |4 H_Annealing | | | | | |5 H_PEM_On | | | | | |6 H_Test | | | | | |7 H_Calibration | | | | | |8 H_Nominal_ | | | | | | Simulation | | | | | |9 H_Science_ | | | | | | Maximum_Data_Rate| | | | | |10 H_Science_ | | | | | | Nominal_Data_Rate| | | | | |11 H_Science_ | | | | | | Minimum_Data_Rate| | | | | |12 (deleted) | | | | | |13 H_Science_Backup| | | | | |14 H_User_Defined | | | | | |15 (deleted) | | | | | |16 (deleted) | | | | | |17 (deleted) | | | | | |18 H_Spectral_ | | | | | | Calibration_ | | | | | | Simulation | | | | | |19 H_Degraded | | | | | |63 H_ME_Test | | |--------------------|---|-----|-------------------|--------------------------| |^INSTRUMENT_MODE | SC| CHAR|"RO_VIRTIS_ |(constant) | | _DESC | | |EAICD.ASC" | | |--------------------|---|-----|-------------------|--------------------------| |(blank line) | |--------------------|---|-----|-------------------|--------------------------| |/* Pointer to navigation | |data files*/ | |--------------------|---|-----|-------------------|--------------------------| |SPICE_FILE_NAME |SET| CHAR|{"xxx",..,"xxx"} or|List of Spice kernels used| | | | |"NULL" |in computation. The last | | | | | |entries provide the names | | | | | |of the DSK or DTM | | | | | |describing the surface. | |--------------------|---|-----|-------------------|--------------------------| |(blank line) | |--------------------|---|-----|-------------------|--------------------------| |/* Cube keywords */ | |--------------------|---|-----|-------------------|--------------------------| |OBJECT | SC| ID |QUBE |(constant) | |--------------------|---|-----|-------------------|--------------------------| |AXES | SC| INT |3 |(constant) | |--------------------|---|-----|-------------------|--------------------------| |AXIS_NAME | EN| ID |(BAND,SAMPLE,LINE) |(constant, provides data | | | | | |organization) | |--------------------|---|-----|-------------------|--------------------------| |CORE_ITEMS | EN| INT |(x,y,z) |Cube dimensions: | | | | | |y, z same as data cube. | | | | | |x constant (# of | | | | | |geometrical values stored | | | | | |= 31 for H or 23 for M) | |--------------------|---|-----|-------------------|--------------------------| |CORE_ITEM_BYTES | SC| INT |4 |(constant) | |--------------------|---|-----|-------------------|--------------------------| |CORE_ITEM_TYPE | SC| ID |MSB_INTEGER |(constant) | |--------------------|---|-----|-------------------|--------------------------| |CORE_BASE | SC| REAL|0.0 |(constant) | |--------------------|---|-----|-------------------|--------------------------| |CORE_MULTIPLIER | SC| REAL|1.0 |(constant) | |--------------------|---|-----|-------------------|--------------------------| |CORE_VALID_MINIMUM | SC| INT |-2147483648 |(constant) | |--------------------|---|-----|-------------------|--------------------------| |CORE_NULL | SC| INT |-2147483648 |(constant) '80000000' hexa| |--------------------|---|-----|-------------------|--------------------------| |CORE_LOW_REPR | SC| INT |-2147483648 |(constant) | |_SATURATION | | | | | |--------------------|---|-----|-------------------|--------------------------| |CORE_LOW_INSTR | SC| INT |-2147483648 |(constant) | |_SATURATION | | | | | |--------------------|---|-----|-------------------|--------------------------| |CORE_HIGH_REPR | SC| INT |2147483647 |(constant) | |_SATURATION | | | | | |--------------------|---|-----|-------------------|--------------------------| |CORE_HIGH_INSTR | SC| INT |2147483647 |(constant) | |_SATURATION | | | | | |--------------------|---|-----|-------------------|--------------------------| |CORE_NAME | SC| ID |"GEOMETRIC |(constant) | | | | |PARAMETERS" | | |--------------------|---|-----|-------------------|--------------------------| |CORE_UNIT | SC| ID |"UNK" |(constant) | | | | | |Depends on parameter | |--------------------|---|-----|-------------------|--------------------------| |CORE_DESC | SC| CHAR|"Parameters are |(constant) | | | | |defined in EAICD" | | |--------------------|---|-----|-------------------|--------------------------| |(blank line) | |--------------------|---|-----|-------------------|--------------------------| |SUFFIX_BYTES | SC| INT |4 |(constant) | |--------------------|---|-----|-------------------|--------------------------| |SUFFIX_ITEMS | EN| INT |(0, 0 ,0) |No suffix present | |--------------------|---|-----|-------------------|--------------------------| |END_OBJECT | SC| ID |QUBE |(constant) | |--------------------|---|-----|-------------------|--------------------------| |(blank line) | |--------------------|---|-----|-------------------|--------------------------| |END | SC|ID | | | |--------------------|---|-----|-------------------|--------------------------| Table 5: Label for Virtis-H on Rosetta. Extra or modified lines relative to the raw data labels are outlined in red (several lines present in the data labels are also removed). Appendix-A FOV definitions The data provided here are copied from the latest Spice kernels provided by ESA, and partly come from documents AD3 and RD7. Virtis offsets in Table 6 have been derived from analysis of Mars fly-by data and star pointing during PC6. Both Virtis channels have their slit in the Y direction. For Virtis-M (both visible and IR imaging channels): - IFOV (pixel size) is ~ 0.000250x0.000250 rad = 0.0143x0.0143 deg - FOV is elongated in the Y direction by 256 pixels: 0.064 rad = 3.67 deg The FOV corresponds to the detector column that is acquired at each time step. For Virtis-H (high resolution point spectrometer channel): - IFOV (pixel size) is ~ 0.000583x0.000583 rad = 0.0334x0.0334 deg - FOV is elongated in the Y direction by 3 pixels: 0.001749 rad = 0.1002 deg The FOV corresponds to the 3-pixel wide area on which the signal has to be integrated; in nominal mode, this integration is performed on-board by the ME. FOV centers are slightly offset from the spacecraft bore sight. The exact positions are given in terms of offset in document AD3 (but are given in terms of rotations around the axes in the Spice kernels). The figures are provided in Table 6, and are used in Fig. 6 to overplot the various instruments' FOV. Table 7 provides a tentative estimate of the location of Virtis boresight in the Osiris images (as stated in RD7). |-----------------|-----------------------------|--------------------------| | | X | Y | |-----------------|-----------------------------|--------------------------| |M_IR-offsets | dx = -0.071619724 deg | dy = -0.025926340 deg| |M_IR-rotations | Rx = -0.025926340 deg | Ry = 0.071619724 deg | |M_vis-offsets | dx = -0.071619724 deg | dy = 0.032945073 deg | |M_vis-rotations | Rx = 0.032945073 deg | Ry = 0.071619724 deg | |H-offsets | dx = -0.0936 deg | dy = 0.0027 deg | |H-rotations | Rx = 0. 0027 deg | Ry = 0.0936 deg | |-----------------|-----------------------------|--------------------------| Table 6: Virtis FOV centers relative to spacecraft boresight |--------------------|------------------------|-----------------| | | X/Y NAC pixels | X/Y WAC pixels | |--------------------|------------------------|-----------------| |M_IR boresight | 992 / 980 | 1043/ 946 | |H boresight | 1013/ 963 | 1039/ 943 | |--------------------|------------------------|-----------------| Table 7: Virtis FOV centers projection on Osiris frames FIGURE06: Details of Rosetta instruments' FOV in the spacecraft X/Y frame. Zs/c points into the page, +Xs/c points to the right, and +Ys/c points down (figure from AD3) Appendix-B Code history - Dec 2006: Written by K. Garceran (from geovirtis, for VEx) - March-2007, S. Erard: Quick & dirty adaptation/merging of geovirtis and geomeg to Rosetta Mars flyby (functional but uses different routines for M and H, to be cleaned and checked later) - Modified to compute geometry cube for Earth and Mars swing-by, P.Lambert - 17-OCT-2007, P.Lambert: adapted for VIRTIS/ROSETTA, MARS FLY-BY. - 23-OCT-2007, P.Lambert: adapted for new new EGSE, VIRTIS/ROSETTA H OK (to process old egse data -> specify /OLD) - 26-OCT-2007, P.Lambert: /UP no more available. /UP is in charge at Rome The raw qubes to process are already updated at Rome - 17-DEC-2007, P.Lambert: from georosmars & georosearth, georos deals with the different target, EARTH (ESB1,ESB2) and Mars. - 10-SEP-2008, S.Erard: Quick update for Steins flyby - 28-APR-2009, F.Henry: /ESB1, /ESB2, MSB, /AFB1 options are no longer available The target is guessed from the database - 30-APR-2009, F.Henry: options /ESB1, /ESB2, MSB, /AFB1 are back in order to be able to use GEOROS without the database - 22-MAY-2009, X.Bonnin: The Moon observation geometry files during the two Earth swing-by (ESB1, ESB2) are now computed correctly (Using TARGET_NAME in file label.) Version 4.2 - 10-JUN-2009, X.Bonnin: The computation of the geometry files for the Steins fly-by (AFB1) is now done with the Digital Shape kernels (DSK) when DTM keyword is set. The dynamically loadable module library (DLM) DSKPLTLIB must be loaded to use DSK files in georos. - 25-NOV-2009, F. Henry; Added the /ESB3 ans /AFB2 flags - 10-DEC-2009, X. Bonnin; Added the LESIA_CKM flag to load the SPICE CK mirror position files produced by the LESIA Version 4.3 - 14-JAN-2010, X.Bonnin: Added DTM for the Earth (GLOBE data) and Moon (CLEMENTINE/LIDAR data). Version 4.4 -21-DEC-2011, S.Jacquinod: The computation of the geometry file for the Lutetia fly-by (AFB2) is now done with the Digital Shape kernels (DSK) when DTM keyword is set. The dynamically loadable module library (DLM) DSKPLTLIB must be loaded to use DSK files in georos. Version 5.0 - 04-JUL_2013, S.Jacquinod: Added the computation of the geometric label parameters Use the keyword /up to updated original RAW files Added a new routine in the pipeline: eastwestlon.pro to compute easternmost & westernmost longitudes in the geometric labels Extract the INSTRUMENT_MODE_ID with no quotes Version 5.1 -08-JUL-2013, S.Jacquinod: read the DATA_QUALITY_ID keyword as a string instead of a float. give it as a string to the structure CatArg for the update of the label Version 5.2 -23-JUL-2013, S. Jacquinod: - Added the computation of the reference frame ID and the definition of the system variable !BODY_FRAME_ID (georos_body_setup.pro) Added the computation of the mean slant distance for geometric labels Added error line display on prompt and writing in the logfile Version 5.3 - 18-NOV-2013, S. Jacquinod: - suppressed the keywords option ESB1, ESB2, ESB3, MSB, AFB1, AFB2 because the name of the mission phases has changed Added the new keyword parameter PHASE_NAME. See the sections "keyword parameters" and "example" hereabove for use Version 5.4 - 26-NOV-2013, S. Jacquinod: correct a bug with the definition of the system variable !COMPUTE_DSK for AST1 and AST2 Version 6.0 - 08-JUL-2014, S. Jacquinod: multiple changes to adapt the routines with the SPICE Version 65 Library - 09-JUL-2014, F. HENRY, S. Jacquinod: added LOAD_MK in order to manually load meta-kernels .ker (in MK/ SPICE_KERNELS directory). This META kernels contains all the names of the kernels that have to be loaded added OFFLINE option to compute geometry with no internet connection added SONC option for the VIRTIS_Coma_products output in ASCII format ('txt' option) or VOtable ('votable') - 15-JUL-2014, S. Jacquinod : correction of a bug for Nominal files where the size is 1*64. The search for the dimension [2] of size(scstr) was false because in this case scstr is a 1D array. correction of a bug : basename doesn't exist, it's the function file_basename in IDL - 08-AUG-2014, S. Jacquinod: replace MTP case by STP case because data are stored by STP on Otarie now - 15-SEP-2015; F. Henry: - .PRE files are created when the RORB kernel file has a predicted start date later than the beginning of the start of the observation. .GEO are created otherwise - 17-JAN-2015; S. Jacquinod : Shape 5 Version 6.1 - 26-JAN-2015; FH + SJ: modification of georos_interp to fix the bug when h_frame_summing > 1 - 12-MAR-2015; FH : modification of the DATA_SET_NAME and DATA_SET_ID for GEO products (data level should be 3 for GEO and 2 for QUB) Version 6.2 - 08-MAY-2015; SJ: correction of the bug concerning the loading of the CATT file and the PCK associated to SHAPE 5 with the good reference frame in order to use the good rotation period of the nucleus - 67P dataset recomputed on May 12 with proper rotation variations, supersedes all previous versions. - JAN-2016: now uses shape model 5 v1.1 - FEB 2016: move the loading of the TARGET PCK kernel before the loading of the RORB, CORB, RATT and CATT kernels files Version 7.0 (25-07-2016, SJ + FH) - July 2016: same code now handles both versions, 6 and 7. - New, extended geometry implemented for 67P. - added /ext to compute old (no /ext flag) or new geometry (/ext present) - added pre as output variable to indicate whether the computed cube is PRE or GEO Version 7.1 21-11-2016 FH - minor bug fix Version 7.2 18-05-2017 FH+SJ - added the shape_version option to choose between shape 5 and 7