Réunion VizieR 28/01/2020

Présents: Marianne B., Coralie F., Gilles L., Giacomo M., Pierre O., Emmanuelle P., Tiphaine P., Patricia V.

Giacomo

Nombre de chiffres significatifs sur les erreurs

Sur une erreur, le nombre de chiffres significatifs est 2 (pour 1e-6, ça donnerait un format 1.0e-6 et pour une erreur de 354254, 3.5e+5 par exemple)... Il faut ensuite adapter le nombre de chiffres significatifs pour une valeur à sa plus petite erreur.

=> Giacomo essaye de rédiger un document un peu général pour donner les nombres de chiffres significatifs de différents paramètres que l'on pourrait utiliser de manière systématique (voir automatique) --sauf cas particuliers qui ne manqueront pas d'arriver.

Il est vrai que la question du format et du nombre de chiffres significatifs revient systématiquement lors du traitement d'un catalogue ; en particulier pour les grands catalogues. => Voir F.-X. à ce sujet

Le problème des arrondis ou de la réduction du nombre de chiffres par rapport aux données d'origine est que parfois, les utilisateurs veulent seulement les chiffres significatifs (et pas qu'on leur en donne trop) mais parfois, c'est plutôt l'inverse, et les utilisateurs veulent retrouver tous les chiffres...

Pour rappel, actuellement, on évite de modifier les fichiers d'origine si le format est déjà donné -- même s'il y a beaucoup trop de chiffres... On le fait surtout pour la conversion FITS vers ASCII et pour les grands catalogues. Par ailleurs, on peut aussi définir un format différent de celui du ReadMe pour les petits catalogues ; cela se fait au moment de l'ingestion dans VizieR (via la commande \vizSet ) mais dans ce cas, le format stocké en base est également différent du ReadMe -- ce n'est pas seulement l'affichage qui est modifié mais aussi le stockage.

On aimerait pouvoir conserver toute la précision des données d'origine et afficher le format qu'on souhaite (et que l'utilisateur pourrait modifier) mais ce n'est pas du tout prêt pour VizieR.

Question subsidiaire : mise à disposition des fichiers d'origine

=> Faire systématiquement un sous-répertoire "ori" qui contient tous les fichiers d'origine tels qu'ils ont été récupéré.
On pourrait envisager par la suite de les laisser en lecture et d'indiquer dans le ReadMe que les fichiers d'origine sont accessibles sur le FTP.

Actuellement, lorsqu'il y a beaucoup de tables, on crée systématiquement une archive ori.tar avec l'ensemble des fichiers d'origine (non accessible par l'extérieur), ce serait peut-être mieux qu'un sous-répertoire ?

Pour rappel, les fichiers FITS sont systématiquement laissés accessibles et les autres tables ne varient généralement pas...

EP : on avait également envisagé une procédure pour les tables .v00, est-ce que c'est toujours d'actualité ? cf. CR du 8 septembre 2015

Que met-on exactement dans la section "Description" du ReadMe ?

Cette section décrit les observations du papier qui ont servi pour les paramètres donnés dans les tables : quels instruments, longueur d'onde, dates d'observation (éventuellement résolution). Elle peut aussi indiquer de quel(s) survey(s)/ref(s) ont été pris les objets s'il n'y en n'a pas trop.
Cette section ne sert pas à décrire les différentes tables du ReadMe avec leurs paramètres ; même si on peut indiquer dans les cas où il y a beaucoup de tables, quelles sont les tables qui présentent des observations ou bien celles qui ont tel type d'objet par exemple pour s'y retrouver un peu...

Voir aussi le document Objectif & définitions du ReadMe réalisé (en 2012) par les documentalistes pour tout utilisateur CDS d'un ReadMe.

=> Giacomo n'aime pas du tout les formulations "We observed..." qui se retrouvent dans cette section car les phrases sont souvent des copier-coller de certaines phrases de l'article. Il continuera à nous envoyer de meilleures descriptions.

A noter : les documentalistes ne peuvent pas passer trop de temps sur un ReadMe et on ne peut pas se permettre de reformuler les phrases des auteurs au risque de créer de mauvaises interprétations mais changer les descriptions n'impliquent pas de recharger un catalogue donc pas de souci pour les modifications.

Gilles

Site de l'AFOEV de nouveau accessible sur cdsarc

Site de l'association française des observateurs d'étoiles variables (AFOEV) hébergé chez nous : http://cdsarc.u-strasbg.fr/afoev/index.htx avec dépôts réguliers sur le FTP https://cdsarc.u-strasbg.fr/ftp/catx/afoev/

Les données temporelles récupérées dans METAtime sont désormais visibles dans les sorties VOTable

Gilles a amélioré la reconnaissance automatique des dates YYYY/MM/DD en format ISO avec une incertitude de 1 jour dans ce cas ; le frame (HELIOCENTER par ex.) est également mieux reconnu.

Dans les sorties VOTable, "timesys" indique le frame, scale, syst et representation (JD, ISO...)

Documentation VizieR à revoir sous Wordpress

Christophe nous a installé un serveur Wordpress pour faire une version Test de la documentation VizieR.

L'idée est de commencer avec la documentation concernant la soumission des données pour VizieR. Voir les pages https://vizier.u-strasbg.fr/vizier/submit.htx et https://cdsarc.unistra.fr/vizier.submit/publication-notes.html

L'URL de VizieR wordpress : http://vizier-doc.astro.unistra.fr/
mise à jour du site: http://vizier-doc.astro.unistra.fr/wp-admin/

=> Emmanuelle va proposer un plan et une organisation dans WordPress pour cette partie "soumission des données" -- à discuter avec Pierre & Gilles dans un premier temps ; puis à voir avec toute l'équipe.

-- EmmanuellePerret - 2020-01-28