ReuV02mars2021 < Documentaliste/VizierDocumentaliste

Réunion du 02/03/2021

Présents (BBB) : Marianne B., Gilles L., Giacomo M., Pierre O., Emmanuelle P., Patricia V.

Pierre

Suite Photometry viewer : catalogues manquants

Suite à la question posée lors de la dernière réunion, il semble que les seuls catalogues à rajouter sont :
UKIDSS - DR6 => fait par Pat en direct
USNO-B1 : les filtres ne sont pas dans METAfilter, ni dans le SVO filter provider et le catalogue est trop vieux pour que les liens vers la doc fonctionnent toujours... => on laisse tomber.

N.B. : NOMAD et PPMXL ont des mag d'origines variées venant d'autres catalogues. => On ne veut pas les ajouter non plus.

Remarque : un cache n'autorisait pas à voir les modifications de la page Photometry viewer directement. => Gilles a supprimé le cache.

Pierre F. a découvert les données temporelles associées aux catalogues VizieR

Pierre O. se demande quels sont les usages qui en seront fait dans Aladin car pour l'instant, la lecture des résultats est compliqué : simple plot avec tous les flux sans distinction dans un cone search.

=> Attention, le résultat n'est donc pas un SED.

Actuellement, les \vizFilter ne concernent que des valeurs moyennes des mag pour un ou plusieurs objets d'un catalogue. Les différentes mesures individuelles pour un même objet qui ont des mesures de temps ne sont pas indexées. Il faudrait pouvoir les relier à la position des objets ce qui n'est pas si simple (parfois dans une autre table, parfois dans la section object du ReadMe) et ce qui n'est pas envisagé par Gilles.

Lorsqu'on a des plots de LCs dans les catalogues, certains liens sont déjà récupérables par Aladin (simplement cliquables ; voir CoRoT par ex.) mais ce ne sera pas toujours le cas. Parfois, les données ne sont pas dans VizieR mais seulement dans le FTP et parfois le lien vers la LC n'existe que dans le titre de la table et/ou dans la section Object...

Donc les LCs dans Aladin, ce n'est pas vraiment possible, pour l'instant, les données temporelles servent plutôt à indiquer sur quelle période de temps le catalogue contient des données.

Ajout mail Gilles :
"Je reviens sur l'idee d'ajouter des donnees temporelle elargies au tables qui ne sont pas presente dans la sortie photometrique.
L'idee n'est pas neuve; elle a deja ete teste et evoque par Sebastien, Ada

un certain nombre de metadonnees permette deja de retrouver un certain nombre de tables : table METAobj, flag ForeignKey/PrimaryKey (\vizFK et \vizPK)

Il ya plusieurs cas:

- les donnees associees - type FITS ou externe en csv.. en lien dans VizieR sont difficilement exploitable dans un cas general: techniquement, mais aussi , nous n'avons pas les filtres de ces donnees associees.

- il y a 2 type de tables sans positions (qui ne sont pas donc pas dispo dans la sortie photometrique):
(1) celles relatives a un objet et dont on retrouve des entrees dans METAobj
(2) celles qui accompagnent une table de position

Le cas (1) ne donne pas beaucoup de points -

La table METAobj liste un certain nombre de tables relative sa une (ou des) positions generales (section Object du ReadMe ou \vizObj du .status)
A noter qu'un catalogue peut avoir plusieurs lignes dans cette table (ce qui ne simplifie pas la chose dans ce cas precis)
A cette liste, on peut extraire des tables qui ont une colonne de temps+une entree dans le SED (si toutefois pour ces tables il yen a)

requetes TAP:

* nombre de catalogues relatifs a un (ou des objets) dans METAobj:
select count(distinct catid) from METAobj
4221 lignes

* idee sur le nombre de catalogues avec time+photometrie (assigne dans METAsed) relatif a un objet (ReadMeObj):
SELECT o.catid, count(s.colid) as n_mag_col
FROM "METAobj" o
join METAtime t on t.catid=o.catid
join METAsed s on s.catid=o.catid and t.tabid=s.tabid
GROUP BY o.catid

49 lignes - soit 49 objets dans des tables "candidates"

ca fait pas beaucoup!

Le cas (2) serait peut etre plus interessant- en se basant les sur Foreignkeys-Primarykeys (\vizFK, \vizPK) on pourrait faire le lien entre une table ayant du temps et sa table prinncipale contenant les positions.

difficile d'en etablir la liste avec TAP, mais en faisant des requetes directes en base, voila ce que j'obtiens comme liste de candidats

catalogue ayant plusieurs table
select distinct catid into temporary table t from metatab where tabid>1;

catalogue ayant plusieurs table + ayant foreign/primary key
select distinct(col.catid) into temporary table t2 from METAcol col join t on col.catid=t.catid where col.flags&2048!=0;

dans la liste , rcherche des tables dans METAsed
select distinct s.catid into temporary table t3 from METAsed s join t2 on s.catid=t2.catid;

dans la liste , rcherche des tables ayant une entree METAtime
select distinct(t.catid) from METAtime t join t3 on t.catid=t3.catid ;

resultat: 259 catalogues "candidats" ayant une table qui pourrait avoir une table ayant du temps et de la photometrie et qui dispose du processus pour joindre la table a sa table principale de position.
Parmi les tables candidates; certaines sont importantes : GAiA DR2 et sa table de transits.

Toujours est il que le résultat qui serait inclus ainsi dans une sortie photometrique++ serait toujours un curieux mélange de résultat basé sur des conesearch et mélangeant différents filtres!

.. (un processus qui pourrait etre completement detache de VizieR) dans VizieR, il serait assez lourd a mettre en place pour un résultat pour un résultat peut être ambigu..

Toujours par rapport au temps: un index global temporel me semble par exemple plus intéressant -"

Réponse Pierre :

Tu as souligne l’hétérogénéité actuelle des timeserie dans  VizieR (catalogues avec un seul objet, LCs en fits / ftp, LCs en table avec des vizFK/PK). Cette hétérogénéité se justifie, elle est le reflet de la diversité des modes d’etude des differents objets observes (on se focalise sur un objet qui est tres exotique vs une série d’objets pour faire une etude comparative vs une etude systématique d’un grand nombre d’objets a des fins de definition d’une reference...)

A cause de cette hétérogénéité je serais aussi pour un processus détaché de vizier, et qui tiendrait a jour un inventaire de toutes les light curve presentes dans VizieR, avec une position, le timesys, le filtre et le lien vers le plot et le “Data as table"

(je pense a ce lien la: [[http://cdsarc.u-strasbg.fr/viz-bin/vizgraph?-s=J/ApJ/870/L1&-i=.graph_sql&--output=tsv]])

Ca pourrait simplifier/uniformiser l’exposition et la consommation des light curve qui existent dans VizieR?

Lien vers des vidéos de Cosmic Dawn III

C'est ici : https://www.youtube.com/channel/UC_8Hfq-kgy8YNvN_8Yke6_g

N.B. : pourrait sans doute intéresser le planétarium !

Emmanuelle

Démo colmeta

On voulait attendre F.-X. & Coralie mais à la demande générale, petite démo de l'outil sur 2 tables ASCII du catalogue J/ApJ/883/78

Options principalement utilisées colmeta -sud :
u : ajoute une unité ; attention : il s'agit de la plus courrante par défaut... Pas forcément ok.
d : ajoute une description si le label est reconnu ; attention : explication n'est pas forcément la bonne - c'est la plus courante aussi.
s : n'écrase pas une unité/description existantes
Le programme reconnait les "Explain column..." du résulat d'une commande anafile (ou fits2a ) et les remplace.
Il aligne les labels (en tenant compte des e_, n_ etc.) et les descriptions pour tenir correctement sur 80cc
Il découpe un label "POSsexa" en RAh, RAm, RAs, DE-, DEd, DEm et DEs si le format de départ est entre A18 et A25 !

Il s'utilise sur tout le ReadMe ou sur une table en définissant les lignes sur lesquelles on veut appliquer la commande (attention, si on veut aligner correctement les labels+description, il vaut mieux le faire sur toute la table plutôt qu'une partie de table...).

colmeta -h donne la liste des différentes options.

La doc se trouve aussi sur GitLab : http://cdsgit.u-strasbg.fr/pineau/catana/-/blob/master/doc/bin/colmeta.md (normalement public)

L'option -p permet de remplir un fichier avec les ucd1+. Je l'ai rapidement abandonné car les paramètres les plus courants sont aussi ceux qui sont reconnus automatiquement au niveau des UCDs... Mais peut-être que si on enrichit encore la liste des descriptions, cela pourrait servir ?

GitLab permet de remonter des "issues" à F.-X. qui les traitent quand il veut, notamment pour ajouter des labels/descriptions supplémentaires qui enrichiront le programme...

N.B. : pour utiliser le programme de cette façon, il faut donc ajouter des labels clairs, reconnus. Cela pourrait permettre d'homogénéiser encore les labels ?

Cat. GPS1+ (I/351) en test

Attendait une réponse de Bertrand pour l'ajout d'IDs...

=> Giacomo relance et sinon on met en ligne.

N.B. : attention pour le GPS1 (I/343), les e_RA, e_DEC sont mal écrits => e_RAdeg, e_DEdeg pour être pris en compte.

Cat. J/ApJS/251/2 : les Fprob, Sprob et Hprob sont compris entre 0 et 1 mais les valeurs sont réparties entre 0e+00 et 0e+313...

Des écarts de valeurs aussi grands ne passent pas en base.

=> Pierre et Giacomo sont ok pour couper à 1% (10^-2).

En utilisant \vizSet pour mettre le format sur 5.3f, VizieR arrondit automatiquement les valeurs ! smile