--
Guillaume Mella - 2020-10-01
2 Octobre 2020
Principales nouvelles fonctionnalités
Ca a bien bougé depuis début septembre : oidb est parfois même en avance sur oidb-beta.
-> un peu plus de détail dans les
releases notes
- permet le lien L0<->L2,3, traitement des release_dates VLTI
- à mené à corriger les releases dates de la collection PIONIER
Amélioration de la protection des données sous embargo
- les datalinks sont maintenant eux aussi couverts
- le traitements est un peu complexe puisque certaines données (pdf) sont partagées entre plusieurs OIFits ayant des releases dates =
- la date la plus lointaine est retenue
- on constate des données 'non science' : calibrateurs, obs de test, commissioning...
- faut-il rajouter des traitements spécifiques (filtrage) ?
Collections privées
- Première mise en place SUV :
- pas encore utilisée
- à étendre avec un partagr de données aux COIs ?
Ancillary data
- première tentative entre L0 et L2 relié sur porgid et obs_id
- ex. d'affichage des liens : http://oidb.jmmc.fr/show.html?id=1281061
- ne relie que le premier L0 aux L2 puisque qu'un OIFIts ne fournit qu'un seul id à travers le keywords ARCFILE
- un lien grosse maille sur la base du progid renvoit vers obsportal/ESOarchive
- peut-on mieux restreindre sur obsportal avec un filtrage supplémentaire par target / date ?
- du coup la meta donnée
interferometer_stations
des granules sera probablement plus simple à remplir depuis l'OIFits
Sollicitations utilisateurs:
Demande d'accès aux données sous embargo
4 demandes courant de l'été pour des données PIONIER
Dépôts de nouvelles données
oidb=> select calib_level, obs_collection, subdate from oidb where subdate > DATE('2019-10-01') group by subdate, obs_collection, calib_level order by subdate DESC, obs_collection;
- KappaTuc : http://oidb.jmmc.fr/search.html?collection=~faa4f229-65a1-4058-a4f2-2965a140586a
- "OIFITS V2"
- aurait du être SUV !
- on note que le dépôt s'est fait en 2 fois
- -> oubli du progid pour certaines granules : c'est maintenant automatique pour progid et obs_id (si dans le fichier format ESO)
- passage en L3 opéré par script avec correction/complement d'info rajouté par script
- Keiichi Ohnaka
- -> nom de collection à corriger
- formulaire modifié suite à une remarque sur le même point de Florian Kirchschlager
- les données des précédents contests ( http://oidb.jmmc.fr/search.html?collection=~7f7fb9ed-350b-415b-bfb9-ed350b515b8c
)
- -> la question du mélange sur les données 'simulées' /observées se pose ?
- pi1 Gruis PIONIER
- Manque obs-id progid dans l'OIFITS -> pas de lien ancillary.
- -> fournir une liste de suggestions à l'utilisateur pour aider à remplir les champs obs_id et progid vide lors de la soumission
Synchro collections externes
- VEGAOBS : synchro mensuelle toujours ok (mode reset)
- CHARA L0 : Changement de méthode en cours : Jeremy J. va déposer le complément pour les L0. Validé sur oidb-beta. Etait initialement alimentée manuellement par tech-group depuis un fichier CSV fournit par Chris F.
- ObsPortal : synchro quotidienne (mode incrémental)
Prochaines étapes OiDB
- MAJ de la doc ?
- Mettre plus en avant l'interface TAP (URL + enregistrement dans le Regristry VO ) / reste à fixer un problème technique sur les jobs asynchrones
- Amélioration / bugfix :
- soumission : fixer le insmod + ajout md5
- ergonomie
- amélioration robustesse (un pb identifié). et peut-etre performance ?
- répercuter le modifs de release_date des L0 sur les L2 (possible d'après les annonces ESO)
- Laisser éditable certains champs après soumissions ? ex description collection...
- Nouveaux plots : timetable ?
Autres projets "databases"
projet SPICA
*porté par l'OCA / Denis, aide jmmc-tech-group à l'étude
JSDC V2.5
- pourrait faire partie d'un lot de services raccroché à un service de catalogues VO TAP ( et OiDB pourrait lui aussi migrer / se modulariser )
AOB ???