Présents:

Ordre du jour

Intro

Modifs de l'été:

• à completer ...

Debrief rapide sur la journée TAP du 17/09/2014 à Paris

organisation des tickets

Patrick finissant son CDD fin Novembre, il serait bien de faire le point sur les actions en cours. Une solution pourrait consister à créer deux milestones sous trac avec comme dates butoires mi-octobre et mi-novembre. Dans le meilleur des cas le milestone mi-novembre pourrait correspondre a ce que l'on attend d'un version publique. Le milestone intermediaire devrait clore les points principaux. Si ok, on cree les milestones et il faudra trier les tickets Ceux ne correspondant a aucun deux milestones pourrait par defaut tomber vers OIDB_FUTURE.

Retour sur le formulaire de soumission de catalogue VizieR

il faut faire d'autres essais

Définir la notion de doublons L{0,1,2,3}

Cette definition doit pouvoir aider à refuser ce qui est deja dans la base ou simplement informer que des données sont partagées entre plusieurs sources.

• quelles sont les conditions de remplacement des granules pour chaque niveau de calibration ? Repartir de la définition de la granule.

Cas présentis:

• nouvelle version de reduction de donnée
• rechargement de nouveaux logs d'observation (cf echange de Denis sur log VegaObs le 02/09/2014 18:22 sur la mailingliste)

Il y a actuellement certaines données qui se recouvrent partiellement sans toujours partager les mêmes metadata.

Dans les deux exemples suivant les deux granules sont probablement issues de la même obs, mais les données différent (nb_oi_vis différent):

• cas1 : données publiées au CDS et présentes dans la collection pionier
• cas 2: collection pionier , JB quelle es l'explication ?

Test backoffice (au moins par Xavier et Myriam) :

maj. documentation

update VEGA

Suite au message de Denis du 02/09/2014, la mise a jour se passe bien. Il manquait des enregistrements qui n'avaient pas de status dans la base vegaobs.

update CHARA

Theo nous a envoyé ( à quelques uns ) des fichiers pour test cet été. Moyennant une petite adaptation de format, les données sont poussée sur oidb cf collection chara sur oidb-beta. reste à faire:

• création d'un compte sur la machine chara pour récupération des fichiers de log ou ils nous envoient leur fichiers .csv sur notre serveur (fréquence à décider).
• fournir l'adresse jmmc-obslog AT ujf... pour récupérer les rapports de fin de nuit: ok. Mais comment prend-on en compte ces observations report ?
• demander une table de correspondance pour identification des dataPi

état des soumissions

Définition des nouvelles actions backoffice :

édition granule, suppression ?

reprise soumissions incomplètes ?

affichage log ?

statistiques (consultation/telechargement) ?

gestion/selection des keywords a mettre a dispo

Specs à completer/modifier

Soumission de donnée par upload de fichiers

• doit-on supporter des archives en entrée ou seulement des oifits (cf ticket #635 )?

Actions non formalisées

• recuperer les dataPi des donnees Pionier

Faire vivre olbin.vo