Les données Eros 1 CCD sont à Lyon, dans le HPSS. Il semble admis que ce serait une bonne idée de les transférer dans iRods, au même titre que les données Eros 2. Le faible volume de données, moins de 300 GB, rend la chose possible. Par chance (!), l’organisation des données prévoie une place pour Eros 1.
L’arborescence des données dans iRods est la suivante :
/eros /eros/data /eros/data/eros2 /eros/data/eros2/fits /eros/data/eros2/fits-headers /eros/data/eros2/fits-props /eros/data/eros2/lightcurves /eros/data/eros2/references /eros/data/eros2/suivis /eros/data/eros2/tars
Il est donc facile de créer une arborescence similaire pour Eros 1 CCD.
/eros /eros/data /eros/data/eros1 /eros/data/eros1/fits ...
Là où la chose se complique c’est lorsqu’il s’agit d’enregistrer ces données dans la base de données.
Deux problèmes se posent : le choix fait d’utiliser les extensions des noms de fichier (leur type) pour représenter certaines caractéristiques des données ; et la multiplication de fichiers de même nom, discriminés uniquement par leur répertoire, ou pire, par le container Tar dans lequel ils résident.
Quelques-uns des problèmes identifiés
Il s’agit d’une première passe. Il y a peut-être d’autres soucis, mais les trois points qui suivent me semblent déjà assez bloquants.
Syntaxe des noms des images et des suivis
Le premier problème concerne principalement les images et les suivis. Le nom est décomposé en différents champs représentant la zone observée, le filtre utilisé, la date, … mais le code de traitement (la réduction) ainsi que le code du CCD sont dans l’extension. On a par exemple des images xb2h2565.fitsr12 ou des suivis x2l233a01B.suivi08. Il convient de noter aussi que le code de traitement n’est pas toujours présent. Par exemple, on trouve des images kb5d1110.fits10, correspondant à des flats coupoles – donc logiquement non réduites, sans code de traitement dans l’extension ; et des images kr5b09zz.fitsr10 – tout aussi flats coupoles, mais ici avec un code de traitement indiquant une réduction – alors qu’aucun commentaire ne fait état d’un tel traitement.
Ceci présente deux difficultés. La première est que c’est contraire à toutes les conventions (implicites) de l’informatique. Il est généralement convenu que le type d’un fichier représente sa nature, c’est-à-dire ce qu’il contient, son organisation, … Tout programme de traitement d’images reconnaitra un fichier jpg ou tiff, mais ignorera un fichier mp3. Qui aurait l’idée de nommer ces photos de vacances .jpg19 ou .jpg18 selon qu’elles datent de cette année ou de l’année dernière ?
La deuxième difficulté tient à la structure utilisée pour la base de données. Images, suivis ou références partagent des caractéristiques communes, programme scientifique, champ, caméra, CCD, et représentent des entités abstraites matérialisées par des instanciations concrètes que sont les fichiers. De la sorte, une même image peut être conservée dans plusieurs espaces de stockage différents – cela reste la même image. Avec l’approche Eros 1, fichier et image sont confondus en une même vue.
Duplication des noms
Le deuxième problème tient à la multiplication de noms identiques. Par exemple, les images composées s’appellent toutes sumB ou sumR avec des extensions fitsr??, quel que soit l’année de prise de vue. La situation est encore pire pour les courbes de lumière qui semblent porter un numéro incrémenté depuis 1, quel que soit le CCD ou l’année. On trouve donc des fichiers 600.time dans tous les répertoires CCD pour toutes les campagnes… Mais ces différents fichiers ne semblent pas correspondre à la même étoile.
Et c’est pas tout
Autre difficulté rencontrée, l’entête FITS de certaines images qualifiées de compositée est notoirement corrompu par l’apparition de 0, en plus ou moins grand nombre, entrainant un décalage dans l’alignement sur 80 caractères des clés FITS. Ces images portent des noms du genre xb2l09.fitsr12. Elles sont conservées dans les collections d’images issues du télescope et ne semblent pas correspondre aux images sumB ou sumR des collections d’images compositées.
Je n’ai pas trouvé ce problème de corruption pour les images réduites, les flats ou les « sum » (mais je suis loin d’avoir tout vérifié).
Choix de migration
La première question est de savoir s’il y a lieu d’indexer les données Eros 1 dans la base de données. Il me semble que cela serait souhaitable – des données non référencées n’ont guère d’utilité.
La deuxième question concerne la normalisation des extensions des noms des fichiers.
La troisième question concerne les fichiers aux noms dupliqués, en faisant abstraction des courbes de lumière qui présenteraient sans doute trop d’efforts à normaliser.
Et il y a également la question de la correction des entêtes corrompus…