Réunion VizieR 16/09/2014

Présents : Marianne B., Sylvain G., Gilles L., François O., Emmanuelle P., Patricia V.

Discussion à propos de la relance de Greg Schwarz pour les tables MRTs de l'AAS

Qu'est-ce qui pourrait nous faire gagner du temps ?
1. Plus de tables en MRTs avec ReadMe quasiment complet (cf. ce qui était fait avant par Greg pour les CDROMs).
=> Point particulièrement délicat : la préparation des tables + ReadMe fait gagner du temps (difficile à mesurer) mais il reste un temps de travail non négligeable : reprendre l'article pour vérifier le ReadMe et les descriptions, et il reste toutes les commandes d'ingestion + UCD à faire... Donc plus de tables MRTs ne veut pas dire plus de tables MRTs dans VizieR : il ne faut surtout pas s'engager à toutes les prendre. Et surtout, cela ne veut pas dire que l'ingestion sera plus rapide au final...
A moins de faire la référence de A à Z ce qui est préférable pour ne pas avoir à reprendre un travail en partie commencé... On pourrait envisager que la personne qu'ils engagent fasse le travail complet (comme Patricia le fait pour A&A) mais le temps de formation est long (~4 mois pour Sylvain) avec dans un premier temps une préparation pour la partie FTP seulement et si tout se passe bien, une ingestion sur une base bêta par exemple...

Il reste une grosse interrogation sur les types de tables qu'ils choisissent de mettre en MRTs de leur côté et les types de tables que nous voudriont en MRTs de notre côté ?
Pour nous les tables de plus de 100 lignes devraient être systématiquement en MRTs et éventuellement les plus petites tables contenant des objets astronomiques. Attention : encore une fois, plus de tables MRTs de leur côté, ne veut pas dire plus de tables MRTs de notre côté (à moins qu'ils fassent tout)...

2. Il faudrait que Greg et le nouvel arrivant viennent voir le travail qui est fait ici à partir des MRTs pour améliorer certaines choses telles que :
- Ne pas laisser une référence bibliographique Auteur, Année mais mettre systématiquement le bibcode et faire les tables refs.dat quand il y a lieu.
- De même pour les tables de notes.
- Faire un ReadMe tel qu'on le fait nous (avec l'indication des colonnes avec des valeurs nulles/99.99, les labels et unités standards, etc.)
- etc.
- On ne peut pas leur demander d'ajouter les UCD1 puisque ce sont les ucd1+ qui sont standards mais il y a peut-être moyen de faire un script pour convertir les ucd1+ avec les descriptions associées en UCD1... Gilles a déjà essayé mais c'est compliqué pour la partie photométrie... François pense que pour le reste, au moins, c'est faisable.

Concernant ce qui n'a pas été mis dans VizieR sur la période 2000-2008...
La priorité est au backlog 2013/2014... Il faudrait déjà voir si ce qu'ils font de leur côté nous fait gagner du temps...

Question Patricia

Cat. J/A+A/568/A126 : 200 millions de rows, découpés en tables ?

Le catalogue est dans le FTP car accès uniquement CDS mais il doit passer par FX/Thomas pour VizieR (pipeline gros catalogue). Il faudrait donc l'enlever du FTP après traitement en gros catalogue...

François a reçu un e-mail de l'auteur à propos de ce catalogue qu'il faudrait lier au catalogue SDSS-DR9. Les tables doivent aussi être regroupées...
=> François regarde...

Question Sylvain

Cat. J/AJ/147/45 : 7.8 millions de rows qui ne passent pas ?

En fait, il devrait passer en catalogue classique...
Il y avait du ménage à faire dans Sybase car les grosses tables (du A+A) sont incluses dans la base automatiquement une fois qu'elles sont entrées entièrement même si l'ingestion du catalogue est interrompue à un moment donné...

=> Gilles a regardé pour nettoyer la base.

Questions Emmanuelle

Toujours pour les gros catalogues : intérêt de J/ApJS/213/12 (images co-added du Stripe 82) si on ne prend que les runs ??

=> François regarde s'il y a moyen de faire un lien depuis les runs donnés dans la table 3 vers les images du site SDSS donné (http://das.sdss.org/ge/sample/stripe82/).

J/ApJS/213/5 : 2 spectres en .fits sensés avoir 4 champs mais une ligne de valeur ??

=> A regarder ensemble pour qu'Emmanuelle comprenne un minimum ce fichier !!

Il y a bien 4 champs, il suffit de faire un fits2a -par fits/dbf8.fits |acut -c1-80|less pour avoir la visualisation des 4 champs... (acut parce que sinon les lignes sont bien trop longues...).

N.B. : dans le même catalogue le AddXCount pour la colonne KCat, fonctionne pour certains KIC mais pas d'autres (notamment 9390653 renvoit bien un résultat mais pas 9730163 alors qu'il devrait avoir au moins un lien) ???

Le AddXCount n'est pas possible avec le gros catalogue KIC...

J/ApJS/213/11 : le graph renvoit une page blanche "ERROR" ?

Le error.log donne :
---
(error) vizGraphBase: SQL parsing exception:Expected "select" (at char 0), (line:1, col:1), referer: http://cdsarc.u-strasbg.fr/local/viz-bin/VizieR-2
---
=> Il s'agit sans doute d'une erreur de syntaxe dans le .graph_sql. A voir avec Gilles...

=> Il y avait des ":" dans le titre du graphe... Il ne faut pas car quelque chose entre deux ":" est interprêté comme une commande SQL...

(Gilles) De plus, une anomalie ne permettait pas d'utiliser les noms de colonnes pour les fichiers ASCII zippé. C'est corrige. (On peut donc utiliser Wave au lieu d'un $4, par exemple...)

-- EmmanuellePerret - 2014-09-16