Note

Cette page a recensé les informations utiles à la mise en place d'acces OV à des donnees issues d'observations en interferometrie optique. Cet echange entre collegues francais s'est étendu au niveau de la communauté olbin voir nouvel espace wiki en 2012.
A partir de 2013 cette page regroupera les discussions en lien avec le nouveau groupe de travail JMMC base de données (pensez à prefixer les nouvelles pages par OiDb.)

Principaux documents

Manuals

• OiDB User Manual ( This web page is edited on the wiki and is cloned onto the oidb portal through the Backoffice dashboard.)
• OiDB Admin Guide

Data Management Plan

Internal documentation

• User Requirements for the Optical Interferometry database
• Specifications
• Software Design
• installation and configuration
• tickets (Auth required)

Mandatory external resources

• jquery
• bootstrap
• existdb
• postgres
• TAPLib, TAP, ObsCore ... TBC

Mini infos twiki

• Enregistrement
• Changement de mot de passe
• Introduction sur le wiki et Tutorial
• Notification des changements de cette page : rajouter la ligne ' Main.VotreLogin : OiDb* ' dans WebNotify

OIDB 2.0

Priorities OIDB 2.0

Towards OIDB 2.0

OiDbObsMapping

Checklist de la mise en production OIDB 1.0

fin mai 2015

fin avril 2015

Réunions

02 Octobre 2020

05 Mai 2019

05 Dec 2018

20 Oct 2017

27 Juin 2017

01 Fevrier 2017

27 Mai 2015

24 Mars 2015

5 Mars 2015

6 Février 2015

23 Janvier 2015

16 Decembre 2014

14 Novembre 2014

19 Septembre 2014

8 Juillet 2014

18 Juin 2014

27 Mai 2014

28-30 Avr 2014

18 Avr 2014

21 Mar 2014

5 Fev 2014

17 Jan 2014

16 Jan 2014 aux VLTI community days

15 Nov 2013

26 juin 2013

31 mai 2013

20 juillet 2010

Une première réunion entre l'OCA et le JMMC a permis d'initier des discussions visant à définir la mise en place de base de données dans l'observatoire virtuel. L'objectif est de faciliter l'acces aux données distribuées réduites (OIFits) en utilisant les standards de l'OV. Nous avons convenu d'itérer sur les points suivants avant une prochaine réunion (octobre) :

• Cas d'utilisation ( Action DM GD )
• Description de l'architecture ( Action JMC GM )

Viendront se greffer des discussions autour:

• de la definition du modele de donnees VO en interferometrie optique ( Action LB )
• de la meilleure methode à mettre en place pour permettre l'identification croisée entre plusieurs bases (cross matching des sources). ( Action SL DB )
• du retour possible sur l'évolution de la norme OIFits et des interactions avec d'autres partenaires (par exemple Nexsci...)

1er decembre 2010

Compte rendu de la reunion (par visioconf)

16 mars 2012

Compte rendu de la reunion (par visioconf)

Informations

Cas d'utilisation scientifiques

GuillaumeMella -18Aug2010

Pensez à la notion de multiplicité dans les attributs que l'on veut manipuler. Par exemple lorsque l'on demande les fichiers ayant une source a une certaine position (conesearch) est-t-il possible d'obtenir un fichier avec plusieurs sources dont certaines pouvant etre a l'exterieur de la zone de recherche. Idem pour les instruments. En fonction des reponses, cela aura un impact sur l'architecture technique mais aussi sur certains tests ou pre-traitements à appliquer. a moins que la base ne comporte que des donnees calibrees (encore faut-il pouvoir indiquer le diametre du calibrateur utilisé...), il faut voir l'impact sur le lien avec les calibrateurs ( dans des fichiers differents ? relier par quel moyen? ).

Quelques idées en tant que futur utilisateur...

• utilisation évidente: requête sur un identifiant pour connaitre/charger... les données OIFITS d'un objet donné existantes dans la base. Ces données devront être "étiquetées" de manière simple de sorte que l'on puisse les présenter. Instrument-lambda-mode-nombre de points-publications associés par exemple. Ces fichiers deviennent alors exportable vers tout autre application capable de les recevoir
• utilisation pour de la R&D: on cherche des données par rapport à certains critères: Imagerie (Y/N), Modelling (Y/N), Quality (1-5), Type of source (UD, binary, elongated disk, ...). Dans tous les cas il est donc nécessaire d'attacher aux données ce type de metadata.

TBD...

Architecture technique

Premiere proposition

Jean-Michel a mis sur le papier ( 20/07/10 ) une premiere version d'architecture. Un prototype va permettre de mieux identifier le service de base de donnees.

Premier prototype

Nous avons proposé de mettre en place un tel service sur la base existante du repository JMMC. Plus d'info sur le prototype (en cours de réalisation lancée le 16 aout 2010)

Methode d'identification croisée d'une étoile entre plusieurs bases

TBD1

Modèle de données

Le modèle de données correspond aux méta données décrivant à la fois une observation et son fichier de données réduite au format OIFits.
Le format OIFits contient déjà certains mots clés (date d'observation, nom de l'instrument et de l'interferometre, ligne de base utilisée, longueurs d'ondes utilisées, coordonnées et quelques informations sur les sources) mais cela n'est certainement pas suffisant pour effectuer des requetes scientifiques (qui, identifiant standardisé des sources, configuration de l'interferometre et des instruments ...)

Dans un esprit VO, toute resource (comme un fichier OIFits) peut être décrit dans un registry VO à l'aide de Resource meta data.

On peut faire le parallele entre oifits et FITS pour l'utilisation de ObservationDM. Ci-dessous un extrait d'un bon fil de discussion sur lea mailing liste IVOA dataAccessLayer

Show... Hide...

The ObservationDM (generic Dataset) is the base model for *describing*
astronomical datasets - it applies to any type of data.  However, when
it comes to an actual dataset instance we are not merely describing the
data, we have an actual dataset with data samples/vectors.  Spectrum
defines a standard for an actual dataset containing 1D spectral data.
It is a special case since astronomy does not have such a standard -
spectra are stored in archives in many different ways, but we needed
some way to get spectral data back to client analysis applications
without having them have to know about every spectral data format
out there.  We do not need something comparable for image data since
we use FITS in this case.

Now it is true that much of what is in SSA and Spectrum is actually
just the generic dataset/observation model, so having a comprehensive
definition of the generic model will be useful, and this could help
streamline a future update to the SSA and Spectrum specifications.
We still need to define how such a generic data model is used in a
particular application (such as SSA) however; it may be necessary to
extend the generic model, specify what is mandatory for the particular
application (such as a DAL query), define unit contraints for the
particular application, and so forth.

SIAV2 has some special needs which are not adequately covered by
the generic models - in particular it relies heavily on FITS WCS
for much of its function.  The image geometry and WCS is different
than characterizing the data (WCS is a spatial calibration not a
characterization, and we need both).  We do not need to respecify
FITS WCS since this is already done by the FITS standards, but we do
need to specify precisely how WCS is used by SIA.  This is a central
part of the access protocol, especially the accessData method.

Characterization is also essential for SIAV2.  In particular we will
need to do some more work to adequately characterize radio data cubes.
Anita covers this well in her Note on radio data which can be found on
the SIAV2 twiki page. 
Doug Toddy

Le travail actuel sur le Observation data model est intéressant car il rassemble des meta données essentielles : WD-ObsCoreDM-0.2 :

• dataproduct_type = 'Visiblity.Image' ou 'Visiblity.Cube' : à discuter
• calib_level = 2 : Science ready data
• obs_collection : identifiant d'une collection de ressources : Typical data collections might be all the data from a particular telescope, instrument, or survey : peut être utile pour définir le couple interféromètre/instrument ?
• obs_id : collection-specific identifier
• obs_publisher_did : IVOA dataset identifier
• access_url : URL d'accès pour télécharger le fichier de données (OIFits)
• access_format : oifits
• access_estsize : file size in KB
• obs_target : name of the target of the observation : 1 seule alors qu'un fichier OIFits peut en contenir davantage; Solution : démultiplier ...
• s_ra / s_dec : RA/DEC (deg)
• s_fov : approximate size of the region covered by the data product. For a circular region, this is the diameter (not the radius) (deg) : a ignorer ??
• s_region : couverture spatiale (adql:REGION)
• s_resolution : resolution spatiale (arcsec)
• t_min : start time of the observation in MJD
• t_max : stop time of the observation in MJD
• t_exptime : exposure time (sec)
• t_resolution : resolution temporelle (sec)
• em_min : longueur d'onde minimum (m)
• em_max : longueur d'onde maximum (m)
• em_res_power : resolution spectrale
• o_fluxucd adql:VARCHAR : ...

Ce data model présente donc l'avantage de contenir déjà de nombreuses informations utiles qu'il serait possible d'étendre pour ajout les aspects interférometriques et mieux caractériser les données (min/max/mean/std dev) pour les données importantes (VIS2, VIS2ERR ...) ce qui est aussi possible en s'inspirant du concept VO Characterisation ... mais étendu à tout type de données (statistiques)

Quelques liens : OIFits standard Aspro data model IVOA Resource meta data IVOA Observation Core data model

TBD1

Retour sur la norme OIFITS

La norme OIFits (version 1) est décrite à l'adresse : OIFits standard

TBD1

Liens webs utiles:

externes:

http://www.ivoa.net	Portail d'entree vers les coulisses techniques dans l'OV en astro
http://www.ivoa.net/Documents/TAP/	Protocole d'acces à des tables pouvant permettre la recuperation d'url vers des oifits en comparaison avec les protocoles SSAP SIAP
http://ivoa.net/Documents/latest/ADQL.html	Langage d'interrogation allant de paire avec TAP ( DSA ne supportant pas encore PQL )
http://registry.euro-vo.org/index.jsp	Un registry permettant de decouvrir des donnees/services

internes: