Myriam Benisty, Patrick Bernaud, Jean-Baptiste LeBouquin, Guillaume Mella, Denis Mourard, Johan Olofsson

Ordre du jour

Etat des lieux

• Nouveautés ( interrogation par requete ADQL libre, test brique VO TAP (gavo/taplib)... )
• Point sur l'implémentation de la granularité
• Point sur la création du backoffice
• Point sur la création du cache local

A discuter

• Qualité des données (ticket #579)
  • difficulté d'un critere à demander systématiquement au dataPI (subjectif)
  • VEGA les dataPi mettent à la main deux champs status + quality flag
  • ACTION: reprendre la formalisation VEGA quality 0 (trash) - 5(tres bon))
• Organisation des tests de soumission : validation et extraction des données et métadonnées (tickets #551 et #607)
• Création de comptes dataPI
  • Vega :
    • Les données L3 doivent arriver automatiquement depuis le CDS ou encourager tres fortement depot sur OIFits
    • Le depot des données L2 relevent de la responsabilité du dataPi
    • Les données L0 sont annoncée de manière publique. *
    • A partir de la fin d'un programme ( 1 ou 2 ans ), l'acces aux données brutes devront pouvoir etre retrouvées pour utilisation par les pipelines par demande de compte. La fin du programme doit être bien définie en amont.
  • Point données Pionier / data publiques/privees
    • les données reduites peuvent porter le obsId
    • tous les PI pionier ont un compte archive ESO
    • se demande si l'on peut uniquement mettre en ligne les données L2 publiques
    • après discussion suite à la réunion, Jean-Baptiste propose de conserver le mode actuel ou l'on affiche les données sous embargo avec l'instrumentPI comme contact. Jean-Baptiste se charge ensuite de fournir les données demandées (qu'il recupere directement depuis le portail avec son mdp sur le serveur qui heberge les données pionier).
  • La duree d'embargo en interferometrie est-elle plus longue que dans d'autres domaines? Il faut vraiment voir si du coup il faut elargir à 2 ans. 1 an semble faire l'unanimité. Voir avec encouragement collaboration.

• Définition d'un obs ID (pourquoi ? comment ?)
  • dans le cas de spitzer ce concept est utilisé dans les papiers pour referencer des pointés précis. (AOR sur Herschel)
  • permettrait de definir une sous partie d'un programme utilisé dans un papier
  • la notion de granule_id doit etre présente

• Quelles colonnes manquent (optionnelles ou pas, le concept est-il finalisé)?
  • Number of telescopes
  • Telescopes configuration (par ex.E1-E2 est a afficher mais faut il pouvoir requeter sur baseline min/max, son orientation...)
    • baseline oui
    • orientation non
  • Run/Program ID
  • Description of the archive * prendre le readme des données CDS
  • Special remarks
  • Observation notes
    • definir les champs dans le formulaire de soumission
  • Quality flag
  • Instrument mode (doit on avoir un dictionnaire ou peut on caracteriser les obs par criteres de resolution spectrale, bande, etc...)
    • lambda central, delta lambda, nb canaux

• wavelength range trop détaillé passer en : optique / proche infrarouge / moyen infrarouge

• • pour aide : ex. de stats pour l'instrument_name des données identifiées comme AMBER par oidb
  • http://jmmc.fr/~swmgr/AsproOIConfigurations/ASPRO2-CONF_2014_0403/ + http://apps.jmmc.fr/exist/apps/myapp/oidb-insmodes.html

• Préparation de la venue de Théo :
  • présentation sur le fonctionnement de la base (prototype L2/L3, comment uploader des données L2/L3 et L0 Vega).
  • Quelles sont les contraintes pour synchroniser les données L0 de CLIMB et CLASSIC PAVO avec l'OiDB (modèle VEGA) ?
  • Point sur la database CHARA (la demande NSF a-t-elle été acceptée ?)

Remarques Denis: Tous les pipelines CHARA ne produisent pas forcement des données oifits, les durées de rétention ne sont pas contrôlées. Theo a l'info sur la politique MIRC. la priorité sera certainement donnée à l'injection des L0.

• INTEROP Madrid
  • Appel a presentations groupe Application
  • Rappel enregistrement