Les suivis Eros 1 CCD sont assez proches des suivis Eros 2 – même si historiquement c’est plutôt l’inverse.
Les outils d’exploration des suivis mis en place doivent donc pouvoir être utilisés. Même s’il faudra sans doute procéder à quelques adaptations. Ce point peut être important car ces outils pourraient permettre de commencer les sauvegardes par une campagne de validation, pour éviter les mauvaises surprises rencontrées avec les images.
La sauvegarde des suivis dans Irods ne devrait cependant pas poser de problème puisqu’une structure existe pour les images, qu’il suffit d’adapter. L’architecture va donc encore une fois suivre l’organisation historique, à savoir une arborescence par campagne et un répertoire par CCD :
/eros/data/eros1-ccd/ suivis/ LMC9192/ 00/ 01/ ... SMC9495/ ...
La différence la plus importante entre Eros 1 CCD et Eros 2 réside dans la logique des productions. Pour l’expérience Eros 2, l’ensemble des prises de vue constituait une même campagne. Les images étaient donc traitées dans leur ensemble, conduisant à des suivis couvrant les sept années d’observation. Pour réduire la taille des fichiers, ceux-ci étaient segmentés en blocs et les analyses étaient conduites par quart de CCD.
Dans le cas d’Eros 1 CCD, les analyses sont menées séparément pour les différentes campagnes mais pour l’ensemble du CCD. Bien que de multiples programmes aient été conduits durant la dernière campagne, il n’existe des suivis que pour le LMC et le SMC.
Tout comme pour Eros 2, pour éviter d’avoir des fichiers de trop grandes tailles, les analyses étaient réalisées sur des sous-ensembles d’images. La différence entre Eros 1 et Eros 2 se manifeste dans les noms donnés aux fichiers : Eros 2 indique le numéro du bloc alors que pour Eros 1, les dates de début et de fin sont utilisées.
La différence entre les conditions de prise de vue se répercute dans les noms des suivis. Dans Eros 2, les codes du champ et de la caméra sont indiqués, ce qui n’a pas d’intérêt pour Eros 1. En outre, les noms Eros 2 intègrent le code du quart de CCD. Enfin, plusieurs campagnes d’analyse ayant été réalisées dans Eros 2, les noms contiennent l’indication de la production.
Toutes ces différences conduisent à renoncer à l’espoir de fédérer les suivis 1 et 2 dans une même structure dans la base de données. Une seconde table doit donc être mise en place.
Cette dichotomie impacte principalement les outils ReportSuivis et GetSuivis.
4 cas peuvent se présenter :
- l’utilisateur indique explicitement le type des suivis cherchés – par exemple par une option d’appel – l’utilitaire effectue la recherche sur la table concernée – le rapport est présenté avec les attributs spécifiques au type des suivis cherchés ;
- la requête est indiquée avec des attributs propres à l’un ou l’autre des types de suivis – l’utilitaire peut donc basculer dans le mode approprié – ce qui correspond implicitement à la situation précédente ;
- la requête ne contient aucun élément permettant d’identifier la nature des suivis – l’utilitaire va donc procéder à deux requêtes, une par table, et présenter deux rapports, un par type de résultats ;
- la requête contient des éléments des deux types de suivi – l’utilitaire doit séparer les attributs spécifiques de manière à construire deux requêtes distinctes – les résultats sont présentés en deux rapports séparés.
Donc en toute logique, ça devrait passer…
Bon ben, ypuka, au boulot !