Avec la fin des migrations des suivis Eros 1 CCD, j’ai repris les archives Tar qui étaient sauvées dans le HPSS, ainsi que les archives des DLT de Marc, afin de m’assurer que rien n’avait été oublié – ce qui est fort heureusement le cas.
Cette vérification m’a conduit à m’intéresser à des archives que j’avais laissé de côté dans un premier temps, et en particulier des archives « SuivisRef », « Composites » et « Composites+Astrometrie ».
Ces archives contiennent des images FITS composées et traitées astronomiquement, des suivis réduits et des références.
Les images composées sont notées comme tel dans leur entête. Je peux imaginer, par analogie avec Eros 2, qu’il s’agit d’images résultant de la sommation de plusieurs images de bonnes qualités destinées à améliorer la détection des étoiles. Il n’y a malheureusement pas de traces sur les images ayant servies au compositage – ou du moins, je n’en ai pas encore trouvé. Tout ce qu’il y a dans l’entête est une clé SUMIMA ayant des valeurs comme 52 ou 53.
Les images « astronomiques » débutent par le même entête que les images composées et se poursuivent par différentes clés faisant référence à WCS Astrometry.net. J’imagine donc qu’il s’agit des images composées retraitées par un programme astrométrique, sans doute pour les caller. Ces images contiennent des informations de création de faisant état de 2013 – bien plus récent que les images composées donc.
Il y a également des fichiers de type ref. Sans doute des références. Impossible d’être plus précis car je ne sais toujours pas lire les références.
Les suivis sont des suivis sans mesure – avec seulement les tables d’étoiles. Ce qui est plutôt une bonne chose puisque contrairement aux références les suivis sont accessibles par les outils ErosDb. Il y a deux catégories de suivis : l’une nommée moy, l’autre nom. Encore une fois, il n’y a pas de notes sur la création de ces fichiers, on ne peut donc que supposer que moy fait référence à une notion de moyenne. Dans la même veine, nom pourrait correspondre à nominal ???
Il y a un fichier par campagne et par CCD.
En tout état de cause, il parait utile de conserver explicitement ces fichiers.
La grosse difficulté est le choix fait par les producteurs de l’époque de donner le même nom a tous les fichiers, à l’exception du code de couleur et du préfixe du suffixe (sisi !). Par exemple, toutes les images composées du CCD 0 s’appellent sumB.fitsr00 et sumR.fitsr00, quel que soit la campagne.
D’abord, c’est pas vraiment mnémonique, et plus grave, c’est complètement incompatible avec la base de données.
Eric Lesquoy avait fini par apprécier la base de données, surtout avec la possibilité de la gérer au travers de TCL. Mais son mantra était de pouvoir reconstruire la hiérarchie des données à partir des seuls noms des fichiers.
Cette idée s’est tellement imposée qu’elle est l’un des fondamentaux de la base de données ErosDB. Une donnée doit avoir un nom unique qui constitue son discriminant, sa clé extérieure. La seule exception à ce principe fondamental concerne les fichiers, qui sont identifiés par leur nom et leur répertoire. La logique sous-jacente est qu’une donnée regroupe les caractéristiques immuables de l’élément : la date d’observation d’une image, le nombre d’étoiles d’un suivi, … alors que les fichiers sont la matérialisation de l’élément dans un espace de stockage. Un élément est unique mais il peut être conservé sur différents médias : des cartouches, le HPSS, Irods… Cette organisation de la base de données a permis d’indexer sans soucis majeurs – du moins sans soucis insolubles – les données Eros 2 et Eros 1 CCD.
Mais il est impossible d’indexer des données portant toutes le même nom !
Une difficulté un peu similaire s’est présentée avec les images callées astronomiquement par Jean-Baptiste (post du 10 Janvier 2019 et du 6 Février 2019). L’astuce avait consisté à changer le nom des images en leur attribuant un code de traitement spécifique.
Je pense faire la même chose pour ces données :
- les références « moy »: sum[BR]moy.ref[00..ref15]
- les suivis réduits « moy »: sum[BR]moy.suivi[00..15]
- les références « nom »: sum[BR]nom.ref[00..15]
- les suivis réduits « nom »: sum[BR]nom.suivi[00..15]
- les images composées: sum[BR].fits[00..15]
- les images composées callées: sum[BR]m.fits[00..15]
Pour les images, on peut adopter la même stratégie que pour les images composées Eros 2: leur affecter le code objet et le code couleur, adopter un code de traitement « c » ou « w », comme dans Eros 2, et utiliser une date arbitraire correspondant au début de la campagne. Il se trouve d’ailleurs que les images composées utilisent déjà cette solution. Elles ont une date artificielle, indiquée dans leur entête par la clé FITS DATE-OBS. Il faudra juste vérifier que cette date est cohérente avec la campagne d’observation.
Pour les suivis, on peut se rapprocher des noms des suivis Eros 1 CCD : le code objet, la date de début, la date de fin, le code couleur, l’extension et le code du CCD. Pour les dates de début et de fin, on peut prendre les premiers et derniers jours des mois débutant et terminant la campagne d’observation, par exemple le 1 Décembre 1991 et le 30 Avril 1992 pour LMC9192, soit le code 1l012d30. Il faudrait sans doute éviter de mélanger les suivis standards et ces suivis réduits. D’où la proposition d’introduire deux nouveaux suffixes : svmoy et svnom. Soit au final x1l012d30.svmoy00 et x1l012d30.svnom00.
Et comme pour Eros 2, on peut attribuer aux références une syntaxe similaire à celle des suivis.
Ceci étant, rien n’empêche de recopier dans une arborescence parallèle les fichiers originaux…
De toutes les façons, les archives provenant du HPSS sont sauvées dans Irods, dans /eros/legacy/eros1-ccd.
Je pense mettre rapidement cette stratégie en œuvre. Peut-être n’y aura-t-il pas beaucoup de réponse à cette proposition, mais comme disait Clémenceau « en démocratie, il faut toujours un nombre impair de votants pour prendre une décision, mais trois, c’est déjà beaucoup trop ».
Bon ben, yapuka…
