OiDb < Jmmc/Software

Tags: view all tags
   $ 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 [[http://www.jmmc.fr/twiki/bin/view/Jmmc/VirtualObservatoryForOpticalInterferometry][voir nouvel espace wiki]] en 2012. %BR% 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.)

%TOC%

---+ [[OiDbDocs][Principaux documents ]]

%INCLUDE{ "OiDbDocs" }%

---+ Mini infos twiki
   * [[TWiki.TWikiRegistration][Enregistrement]]
   * [[TWiki.ResetPassword][Changement de mot de passe]]
   * [[TWiki.ATasteOfTWiki][Introduction sur le wiki]] et [[TWiki.TWikiTutorial][Tutorial]]
   * Notification des changements de cette page : rajouter la ligne ' =Main.VotreLogin : !OiDb*= ' dans WebNotify

---+ OIDB 2.0
---++ [[priorities20][Priorities OIDB 2.0]]
---++ [[rdmap20][Towards OIDB 2.0]]
---++ OiDbObsMapping

---+ Checklist de la mise en production OIDB 1.0
---++ [[CL27052015][fin mai 2015]]
---++ [[CL27042015][fin avril 2015]]

---+ Réunions
---++ [[OiDbReunion02Octobre2020][02 Octobre 2020]]
---++ [[OiDbReunion05Mai2019][05 Mai 2019]]
---++ [[OiDbReunion05Dec2018][05 Dec 2018]]
---++ [[OiDbReunion20Oct2017][20 Oct 2017]]
---++ [[OiDbReunion27Juin2017][27 Juin 2017]]
---++ [[OiDbReunion01Fev2017][01 Fevrier 2017]]
---++ [[OiDbReunion27Mai2015][27 Mai 2015]]
---++ [[OiDbReunionCDSMar2015][24 Mars 2015]]
---++ [[OiDbReunionMar2015][5 Mars 2015]]
---++ [[OiDbReunionFev2015][6 Février 2015]]
---++ [[OiDbReunionJan2015][23 Janvier 2015]]
---++ [[OiDbReunionDec2014][16 Decembre 2014]]
---++ [[OiDbReunionOct2014][14 Novembre 2014]]
---++ [[OiDbReunionSept2014][19 Septembre 2014]]
---++ [[OiDbReunion8July2014][8 Juillet 2014]]
---++ [[OiDbReunion18June2014][18 Juin 2014]]
---++ [[OiDbReunion27Mai2014][27 Mai 2014]]
---++ [[OiDbReunion28-30Avr2014][28-30 Avr 2014 ]]
---++ [[OiDbReunion18Avr2014][18 Avr 2014 ]]
---++ [[OiDbReunion21Mar2014][21 Mar 2014 ]]
---++ [[OiDbReunion05Fev2014][5 Fev 2014 ]]
---++ [[OiDbReunion17Jan2014][17 Jan 2014 ]]
---++ [[OiDbReunion16Jan2014][16 Jan 2014 aux VLTI community days]]
---++ [[OiDbReunion15Nov2013][15 Nov 2013]]
---++ [[OiDbReunion26June2013][26 juin 2013]]
---++ [[OiDbReunion31May2013][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 )
L'idée serait de mettre en place un prototype permettant ensuite de remonter les discussions dans la communauté VO. Nous pourrions aussi en profiter pour reboucler avec nos collegues du CDS.

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

[[OiDbReunion01Dec2010][Compte rendu de la reunion (par visioconf)]]

---++ 16 mars 2012

[[OiDbReunion16Mars2012][Compte rendu de la reunion (par visioconf)]]

---+ Informations
---++ Cas d'utilisation scientifiques

   $ Main.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.
Voili, voila...

---+++!! 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 [[http://apps.jmmc.fr/oidata][repository JMMC]]. Plus d'info sur [[OiDbPrototype][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.<br />
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
%TWISTY{
mode="div"
showlink="Show..."
hidelink="Hide..."
showimgleft="%ICONURLPATH{toggleopen-small}%"
hideimgleft="%ICONURLPATH{toggleclose-small}%"
}%

<verbatim>
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</verbatim>

%ENDTWISTY%

Le travail actuel sur le Observation data model est intéressant car il rassemble des meta données essentielles : [[http://www.ivoa.net/internal/IVOA/ObsDMCoreComponents/WD-ObsCore-1.0-20100521.pdf][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-specific identifier
   * obs_publisher_did : IVOA dataset identifier
   * 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 :
[[http://www.mrao.cam.ac.uk/research/OAS/oi_data/oifits.html][OIFits standard]]
[[JmmcAsproDataModel][Aspro data model]]
[[http://ivoa.net/Documents/REC/ResMetadata/RM-20070302.html][IVOA Resource meta data]]
[[http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/ObsDMCoreComponents][IVOA Observation Core data model]]

---+++!! TBD1

---++ Retour sur la norme OIFITS

La norme OIFits (version 1) est décrite à l'adresse : [[http://www.mrao.cam.ac.uk/research/OAS/oi_data/oifits.html][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 [[http://www.ivoa.net/Documents/latest/SSA.html][SSAP]] [[http://www.ivoa.net/Documents/SIA/][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:
| http://www.jmmc.fr/twiki/bin/view/Jmmc/OIFITSTwoProject | discutions préparation oifits V2 |
Topic revision: r61 - 2020-11-06 - GuillaumeMella