Date: 5 mars 2015

Présents: Xavier, Gilles, Laurent, Denis, Guillaume

Situation/recapitulatif technique du projet

• Patrick à bien terminé son CDD et repart sur un autre projet sur le Campus. Nous restons donc en contact. Il remercie le groupe et a beaucoup apprécié cette expérience.
• le probleme d'acces au fichier uploadé à été fixé. Les : ne posent pas de problème.
  • a faire : un petit test avec un nom de fichier qui valide l'ensemble des caractères supportés
• Infrastructure :
  • Suite à des départs de personnels à l'OSUG-DC, des questions se posent sur l'hébergement. 2 scenario possibles à confirmer d'ici mi-mars: on continue sur la nouvelle infrastructure ou on repart sur l'ancienne en prévoyant une migration.
• Reprise du developpememt en cours par Guillaume et Laurent

Priorités absolues

Soumission de fichiers

prise en compte du nom de datapi

Myriam a eu soumis des fichiers mais l'info datapi n'y figurait pas.

-- GuillaumeMella - 12 Mar 2015 : probleme fixé. d'ailleurs obs_creator_name prend aussi la meme valeur. La même logique est appliquée pour les catalogues Vizier en prenant le nom du premier auteur.

data quality

-- GuillaumeMella - 12 Mar 2015

• Un selecteur est disponible uniquement pour les fichiers L2. La modif peut se faire granule par granule. un selecteur permet une modif sur toutes les granules d'un fichier.
• L'utilisateur peut choisir les niveaux de 0 à 4 suivant la nomenclature du ticket #579
• Si l'information quality_flag est vide le portail affiche Unknown

Questions en vue d'ameliorer la consistence et faciliter les analyses (avec des histogrammes ou subset dans topcat par ex ...):

• laisse-t'on les champs vides pour les L0 ?
• laisse-t'on les champs vides pour les L3 ? ou met-on Science ready par defaut ?
• doit on considerer une info vide equivalente a Unknown ou Undefined ?
• Quid des quality levels de la collection PIONIER ?

Au niveau de l'ergonomie:

• rajouter un tooltip sur le selecteur general par fichier qui modifie toutes les granules d'un coup

filtre bibcode donnée L3 #607

Laurent a commencé à reprendre le validateur.

A detailler

• tests à faire insname / insmode / coordonnées

En interne au moins, avoir un historique des versions d'OIDB avec leurs machines et adresses respectives.

Publicité de l'interface TAP.

Flux RSS pour suivre les activités de download/upload.

affichage du contact

ok mais comment ?

rajout de fichiers aux collections

peut-etre moins prioritaire

documentation + infos site web

• relire la doc
• rajouter un paragraphe au sujet du cookie pour l'acceptation des conditions d'usage
• pages web : revoir le contenu du bandeau en fin de page avec version affichée plus clairement (décliner le statut prod/beta) + lien top

verification des données

• consistence des informations de contact:
  • il y a d'anciens fichiers PIONIER qui n'ont pas de datapi

Points non blocants

L0 ESO mis en service après la mise en service d'OIDB 1.0.

Action est de vérifier les L0 VEGA pour OIDB1.0.

frequence de mise a jour L0 Vega

En pratique il y a environ 4 runs VEGA entre avril et aout. La synchronisation avec la base VegaObs est déclenchée sur demande. Denis a la responsabilité de déclenchement cette synchro.

Calendrier

• 16 mars deadline finacement ASOV : on demande une mission ASOV pour participation a Interop
• Reunion avec collègues du CdS l'am du Lundi 23 mars à préparer.
• Interop Xavier interessé mais pas sur pour Sesto (15-18 juin). Financement ESO probable.
• Meeting CHARA dans 15 jours : Xavier a passé des slides à Denis pour une demo/presentation ainsi que pour demander des inputs à Chris et à Theo:
  • Transmission automatique des log L0 CLIMB/CLASSIC (+ JOUFLU?) en format csv
  • Table des emails et noms des dataPi CHARA (demande en attente)
  • Possibilité d’arriver sur l’abstract d’un programme en cliquant sur une granule L0

• VLTI community day 25/06/15: abstract soumis par Xavier.
• Deadline release V1.0 : debut avril si les priorités absolues sont fixées