Réunion VizieR 13/03/2018

Présents: Marianne B., Gilles L., Pierre O., Emmanuelle P., Patricia V.

Pierre

Question d'un utilisateur sur l'erreur de la période pour Polaris

Dans VizieR, recherche avec "Polaris" dans 2" + "Go" (donne directement les résultats des tables - contrairement à "Find" qui donne la liste des catalogues où il y a des résultats).

=> La période de 3.9696 du GCVS est reprise dans différents catalogues. On n'a pas l'erreur. Peut-être dans le papier d'origine (1983ApJ...274..755) ?

Discussions sur les time-domain entre Ada, Pierre, Seb

Ada doit nous présenter le résultat des réflexions sur le sujet. En bref, l'idée est d'ajouter des métadonnées - un peu à la manière du \vizFilter - pour que les catalogues contenant des données temporelles soient interrogeables.

Pourquoi la colonne SimbadName est en partie vide alors qu'on retrouve les objets par position ?

La colonne SimbadName est construite par les documentalistes de l'équipe VizieR lors de la préparation du catalogue en se basant sur les noms d'objet.

Première constatation : il peut y avoir des objets créés dans SIMBAD (ou des identificateurs ajoutés dans SIMBAD) entre la mise en ligne dans VizieR et l'étude de la référence en réunion =g= plusieurs mois plus tard.

De plus, il s'agit de retrouver les noms SIMBAD correspondants aux identificateurs donnés dans la table. On utilise la commande getobj qui nous liste tous les noms retrouvés dans SIMBAD et ceux qui ne le sont pas (éventuellement le getobj+c nous permet de vérifier que l'objet retrouvé dans SIMBAD a un type d'objet qui convient : par exemple amas de galaxie et non pas galaxie... mais il ne va pas beaucoup plus loin). On essaye ensuite de recréer les bons noms SIMBAD lorsque c'est possible. On peut éventuellement chercher quelques noms par position mais cela devient vite coûteux en temps et on ne se substitue pas à l'équipe COSIM qui a un programme très efficace pour faire les xid par coo et ajouter les bons IDs le cas échéant. Les IDs qui ne sont pas sûrs ou pas retrouvés sont laissés vides.

Dans un deuxième temps, lorsque les documentalistes de l'équipe COSIM ont retrouvés tous les noms (ou une partie des noms -- il arrive que tous les objets ne soient pas ajoutés dans SIMBAD), elles nous renvoient la liste des identificateurs SIMBAD pour les catalogues où la colonne SimbadName est à compléter/corriger.

A ce propos, on a déjà évoqué quelque fois le problème des listes renvoyées par l'équipe COSIM qui donnent l'identificateur principal de SIMBAD, lequel n'a parfois plus rien à voir avec l'identificateur qui était donné dans la table. Voir CR du 28 février 2017 pour J/ApJ/806/L35, par exemple (ou cas du J/ApJ/811/91).

J/A+A/594/A79, table 4 : [Fe/H] sont tous à -1.16 ?

=> Patricia voit si elle a déjà contacté les auteurs à ce sujet...

Problème Mihaela avec le UCAC4 ?

=> A priori, résolu...

Vu avec Mihaela : non résolu via VizieR mais ok par TAPVizieR.

Le problème est que lorsqu'on interroge le UCAC4 avec une liste d'identificateurs, le résultat sur cdsarc donne une liste, comme si tout le monde avait été retrouvé, sauf que les paramètres du premier objet sont répétés pour chaque ligne.
Dans VizieR, le résultat donne des "unexplained error" - ce qui est moins trompeur :
##
The following problems were encountered in this VizieR run:

****Internal buffer cst2sql overflow in: =416-080692=416-081061=416-081242=417-079155=417-079447=417-079626=417-080245=417-080338=417-080863=417-081147=418-082252=418-082304=418-082483=418-082862=418-082903=418-083178=418-083285=418-083408=418-083528=418-083959=418-084108=418-084527=418-084752=418-084771=419-080893=419-081219=419-081341=419-081360=419-081952=419-082162=419-082206=419-082260=419-082656=419-082685=419-082875=419-083035=419-083120=419-083299=420-083843=420-084385=420-084475=421-021388=421-021435=421-021454=421-021507=421-021554=421-021565=42 ...(etc) 
****Unrecognisable token in: =416-080692=416-081061=416-081242=417-079155=417-079447=417-079626=417-080245=417-080338=417-080863=417-081147=418-082252=418-082304=418-082483=418-082862=418-082903=418-083178=418-083285=418-083408=418-083528=418-083959=418-084108=418-084527=418-084752=418-084771=419-080893=419-081219=419-081341=419-081360=419-081952=419-082162=419-082206=419-082260=419-082656=419-082685=419-082875=419-083035=419-083120=419-083299=420-083843=420-084385=420-084475=421 ...(etc) 

###

Problème Tiphaine avec un \vizPosition donnant des messages d'erreurs "Sesame" bizarres ?

=> Gilles va voir directement avec elle. Pas de souci de son côté. Peut-être un problème temporaire ?

Emmanuelle

Présentation services CDS le 29 mars dans le cadre d'une journée documentation astro en France

Le 29 mars, une petite délégation de documentalistes du CDS (Soizick, Evelyne, Fabienne, Mihaela et moi) vont à Paris pour entretenir des relations diplomatiques avec les bibliothécaires/documentalistes spécialisées en astro en France. La journée s'intitule "La documentation au sein des observatoires : état des lieux et perspectives" et on fait une présentation toutes les 5, d'une quarantaine de minutes, dans le cadre de la session "Diffusion et valorisation de la recherche en astrophysique".

Il y aura une partie VizieR d'environ 8 minutes que je vais donc axer sur la valeur ajoutée aux données et la diffusion des catalogues VizieR. D'où ma question à Gilles pour avoir un exemple de la manière dont on peut retrouver les données VizieR à partir de services VO.

Gilles donne l'exemple du GAVO registry (côté VO Allemagne) : http://dc.zah.uni-heidelberg.de/wirr/q/ui/fixed que l'on peut interroger par cone search, UCD, auteurs, mots-clefs...
Le registry utilise un protocole OAI-PMH pérenne : les données ne sont jamais supprimées [mais elles peuvent être cachées].
C'est ce protocole qui permet aux catalogues VizieR d'être retrouvés dans des logiciels tels que TOPCAT.
Il existe d'autres registry VO de ce type -- en Espagne par exemple avec le fameux SVO. Voir Seb pour plus d'infos.

J/ApJS/234/2 : Tables d'URLs pour le GALFA-HI DR2

L'archive GALFA HI demande un mot de passe pour accéder à certaines données mais les URLs complètes données dans les tables devraient fonctionner pour permettre à l'utilisateur de télécharger le fichier FITS directement (c'est le cas depuis le journal)... Sinon intérêt de la table ??

Il y a visiblement dans les ~2To de données de cubes en FITS.
=> Vérifier si Aladin a récupéré les données mais plutôt pas pour nous...

Emmanuelle : Mihaela & Pierre F. sont prévenus, ils attendaient la publication de la DR2 (qui n'est annoncée que dans un lien "arXiv comming" sur le site de l'archive).

J/ApJS/233/6 : graph_sql_sp avec des spectres en .txt (ASCII aligné) ?

Les spectres sont décrits dans le ReadMe sous sp/*. Le fichier est bien défini dans le .status et la variable "file" mais le "type of resource" n'est pas compris d'après la commande vizgraph -d ...
Comment définir les paramètres dans le programme qui visiblement ne retrouve pas les données (que ce soit avec le nom des labels ou avec $1, $2, etc.) ?

=> Gilles regarde si c'est possible...

J/ApJ/842/60 : lorsqu'on ouvre un sous-ensemble des tables dans un PopUp (Col. Nv), le nom de l'objet n'est pas répété => les liens dépendants de ce nom dans cette pop-up ("LC" mais pourrait aussi être un SimbadName) sont morts ?

=> Oui, c'est fait exprès. C'est la commande \use{vPop} qui ouvre un pop-up où les noms ne sont pas répétés...

\vizAddCount{ table1 }{ Nv }{table5 Gal=@{Gal}}{dbtype=i1 fmt=3d}{+Gal}\
  {\use{vPop}\
  \ucd{NUMBER}Number of variable stars for this galaxy \linkRole{table 5}}

=> Du coup, ne PAS utiliser vPop lorsqu'il y a des liens dépendants du nom dans les sous-ensembles...

On cherche un équivalent pour ouvrir la table simplement dans une nouvelle fenêtre. Gilles propose à contre-coeur un \use{title} qui devrait ouvrir une nouvelle page avec en titre "title"...

Emmanuelle : J'ai testé avec un \use{Variables} dans le \vizAddCount , on obtient toujours le bon nombre de sources en rouge. Par contre, il n'y a plus de lien du tout.
Si je ne mets pas du tout de \use{vPop} , je confirme qu'il y a un lien qui remplace tout si on oublie de faire le clic droit ou le clic du milieu pour ouvrir dans une nouvelle fenêtre.

=> Gilles voudrait homogénéiser la manière dont les liens sont faits : il y a différentes méthodes et différents résultats au sein de la base mais ce n'est pas pour tout de suite...
Pour rappel, un lien qui ouvre une pop-up s'affiche en vert dans VizieR.

J/ApJ/842/118 : Liens vers refs ne fonctionnent pas ?

=> A priori, problème de syntaxe dans le .status : la deuxième accolade donne différentes colonnes, il faut donc laisser vide l'ancre finale pour que la colonne interrogée soit celle où l'on se trouve...

\vizMore{ table8 }{ * Ref r_* }{ \ifmatch{Tab*}{@{}} {@{}} \else \
  \vRef{-source=@{@cat}/refs\&Ref=,@{}}{@{}} \fi }
\vizMore{ table15 }{ * Ref* }{ \vRef{-source=@{@cat}/refs\&Ref15=,@{}}{@{}} }

Et non pas, on-oublie-la-moitié-des-colonnes avec :

\vizMore{ table8 }{ Ref r_* }{ \ifmatch{Tab*}{@{r_*}} {@{}} \else \
  \vRef{-source=@{@cat}/refs\&Ref=,@{}}{@{}} \fi }
\vizMore{ table15 }{ * Ref* }{ \vRef{-source=@{@cat}/refs\&Ref15=,@{Ref}}{@{}} }

!!!!!!

J/ApJ/843/33 : min/max des longueurs d'onde pour les images dans les données associées ?

Cas 1 : Herschel 70. On peut aller chercher l'information dans METAfilter pour voir qu'il y a un dlambda de 20 et mettre min à 50 et max à 90 - est-ce qu'il vaut mieux faire ça ou bien laisser 70 et 70 puisqu'on a que cette info dans le Header ?

=> Si on a l'info, il vaut mieux être plus précis et dans ce cas indiquer 50-90.

Cas 2 : pour les différents filtres SOFIA, les Header indiquent différentes lambda centrales mais en texte ("31.5um" par exemple) que le programme ne peut pas interpréter. On a mis partout les min-max pour l'ensemble des filtres, ok ?

=> Puisqu'il faudrait modifier le mapping à la main image par image, il vaut mieux mettre un range global dans ce cas, effectivement.

=> A voir : il est a priori possible d'indiquer une formule dans le mapping pour ajouter +/-20 à une valeur mais Gilles n'en est pas certain...

-- EmmanuellePerret - 2018-03-13