Tags:
create new tag
, view all tags

Réunion VizieR 02/05/2017

Présents: Marianne B., Sylvain G., Gilles L., Pierre O. (en deuxième partie), Emmanuelle P., Patricia V.

Gilles

Page de suivi accessible pour les documentalistes afin de modifier les dates de Release

L'URL qui fonctionne est http://cdsarc.u-strasbg.fr/follow/index.gml (on ne sait pas pourquoi cela ne fonctionne plus sans la partie /index.gml ??)

Le terme "extended to N days" s'appliquait à partir de la date du jour et pas à partir de la Release date... Nous avons donc modifié la page pour ajouter le titre "Change release date" à la colonne. Les termes désormais affichés sont "Release in N days".

Pour info:
La colonne "Comment" contient le commentaire éventuel de l'astronome, qui a pu ajouter un tag pour signifier une modification à faire -- une petite étiquette bleue s'affiche à côté du bouton qui permet de modifier la date de release dans ce cas.
Si un documentaliste voulait faire la modification indiquée dans le commentaire, pour l'instant, il n'a pas de moyen d'indiquer à l'astronome qu'il l'a fait via cette page de suivi.

Note 1 : Concernant les commentaires pour les A&A du type "le lien en haut du readme donne "Bibliographical reference not found in the database : 2017A...", on rappelle que, souvent, les catalogues A&A sont mis dans VizieR en même temps que le papier a été publié alors que la référence SIMBAD sera créée plus tard. Il est donc normal que le bibcode ne soit pas trouvé dans SIMBAD tant que la référence n'a pas été créée.

Note 2 : Concernant le commentaire "dans la description, le nom du catalogue J/A+A/527/A145 devrait être un lien". On a effectivement un problème avec les bibcodes, références catalogues ou URLs qui sont suivis par un point. Si le caractère suivant le lien est un ";", ",", ":" ou tout autre caractère que ".", le lien fonctionne - sinon non. Dans ces cas là, généralement, soit on enlève le point, soit on met un espace devant le point.

Donc, ok pour modifier les dates de release du côté des documentalistes afin que l'astronome n'ait, dans la mesure du possible, qu'une liste de catalogues terminés, sans problème/complément d'information en cours.

Note : les références sans couleur sur la page de suivi, ne sont pas dans la liste des catalogues à valider en priorité (c'est le cas pour ceux dont on repousse la date).

Dans l'ordre des priorités, il y a d'abord les rouges (déjà publiques), les oranges (terminés depuis environ 1 mois) et enfin les verts (terminés depuis environ 15 jours).

Quid des 30 jours et de la validation de l'astronome qui rendrait la référence publique ?

Gilles se sert du statut "In prep" (voir dans METAcat, col. status : 0x10=inPrep). Tant que le catalogue est "inPrep", c'est à dire que l'on a répondu "no" à la question "Release now" et qu'un astronome n'a pas validé la référence, le catalogue reste inPrep donc n'est pas miroré sur VizieR (ni les autres miroirs). Il n'y a donc plus de J-30 qui pousse la référence dans VizieR automatiquement au bout de 30 jours.

GL: le principe suivant de copie sur vizier et les miroirs n'est pas encore base sur le statut in_pre: il faut attendre pour cela la prochaine "mise en prod" (prévu en mai). Jusqu'à ce jour le principe de copie est basé sur 30 jours de latence.

Pour résumer les cas où la référence est mise publique :

1. Lors du 2v , on répond "yes" à la question "Release now". Dans ce cas, il n'y a pas de passage par un statut "In prep". C'est le cas pour la plupart des A&A par exemple. En l'occurrence, les références sont publiques mais on veut toujours savoir si un astronome a validé ou non la référence ultérieurement.

2. Lors du 2v , on répond "no" à la question "Release now". La ref. devient alors "inPrep" et est consultable dans le VizieR local (cdsarc). Après un certain temps après la date de Release (locale), la référence apparaît en couleur dans la liste des catalogues à valider. Tant qu'elle n'est pas validée par un astronome, elle reste "inPrep" et n'est donc pas mise en ligne.

GL: le principe suivant de copie sur vizier et les mirroirs n'est pas encore base sur le status in_pre: il faut attendre pour cela la prochaine "mise en prod" (prévu en mai). Jusq'a ce jours le principê de copie est base sur 30jours de latences.

Emmanuelle

J/ApJ/832/190 (redmine #2586) : suite - trop de précision affichée pour les coo !

Suite à la réunion du 11 avril 2017, j'ai utilisé astropos pour diminuer la précison sur RA qui aurait dû être celle de la déclinaison (vérifié avec l'auteur). Néanmoins, le fichier obtenu, avec des précision de l'ordre de l'arcminute, ne reste pas tel quel et s'affiche toujours avec des précisions de l'ordre de l'arcsec dans VizieR...

Le precoo=3 qui permettait d'ajuster les précisions n'est plus disponible.

Gilles doit voir avec Laurent et Pierre car les modifications sur les précisions des coordonnées sont risquées. C'est Laurent C. qui avait fait remonter que pour retrouver les coordonnées d'origine à partir des positions ICRS calculées, il ne fallait pas réduire la précision sur les coordonnées.

Néanmoins, on fait remarquer que dans ce cas, on ne veut pas diminuer la précision sur les coordonnées mais les afficher telles quelles et pas avec une précision supplémentaire inexacte...

Une solution pourrait être de garder toute la précision pour les calculs mais de n'afficher que la précision d'origine.

Filtres à ajouter dans METAfilter

Le SVO ne contient pas tous les filtres et ils évoluent plus rapidement que prévu... Par exemple, 5 filtres J différents pour Blanco/ISPI...
Pierre regarde tous les filtres qui ne sont pas reconnus automatiquement pour le Photometry viewer et nous dit si certains doivent être ajoutés dans METAfilter ou si on peut utiliser un filtre proche.
La liste des filtres à ajouter est sur la page du Twiki : http://cds.u-strasbg.fr/twiki/bin/view/Documentaliste/VizierDocumentaliste/ListeFiltres

Pour faciliter l'entrée des nouveaux filtres par Gilles (qui le fait manuellement), on peut ajouter le lambda effectif (similaire au lambda_0_) et le FWHM.

J/ApJS/224/26 (redmine #2628) : des flux en erg/s ?

A priori, ce ne sont pas des flux mais des luminosités (donc seraient en log)...

=> A voir avec Pierre.

J/ApJ/807/178 (redmine #2671) : table avec des amas de galaxies mais coo de la galaxie la plus brillante...

SIMBAD n'a considéré que les galaxies (pas de taille pour les amas de toute façon). Dans ce cas, ne pas ajouter un SimbadName tel quel mais ajouter les noms des galaxies dans une colonne indiquant "BCG: link to brightest galaxy of the cluster in SIMBAD" avec un \object{@{}} pour faire le lien vers SIMBAD.

Note : il n'est pas rare que les tables d'amas donnent les identificateurs et coo des galaxies les plus brillantes dans les amas et pas des amas eux-mêmes...

-- EmmanuellePerret - 2017-05-02

Topic revision: r4 - 2017-05-09 - EmmanuellePerret
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback