DALFuture < IVOA

<br /> <!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->

---+ DAL Future - discussion page

This page is meant to gather opinions, feedback and proposals for DAL future (see [[http://wiki.ivoa.net/internal/IVOA/InteropOct2016DAL/DAL_Future.pdf][Trieste 2016 Fall Interop presentation]]).

The underlying question is what will be the main evolution of the DAL protocols in a near future (SIA, !SODA, TAP, !ADQL, !DataLink, etc.).

The main drivers are:

   1 CSP priorities : what is achieved and what is not achieved.
   1 Feedback from implementation of recently recommended protocols (SIA, !DataLink, !SODA, TAP new version)
   1 Multidimensional data access roadmap as established in october 2013 in Hawaï (Fall Interop + ADASS).
Properties to consider:
   * Data Type
   * Functionalities
   * Software Design
   * Position in IVOA landscape
(see [[http://www.adass2016.inaf.it/index.php/participants-all/4-poster/163-molinaro-marco][ADASS XXVI DAL poster]] for reference)

Contribution can take the usual forms: linked pages to topics listed below (or added ones), mailing list follow up from the topics.

(please, when creating a page to link from a topic here, use a DALFutureTopic TWiki name for the new page)

---+++ Data Type

Add Time Domain ( *HIGHEST Scientific priority: see [[http://wiki.ivoa.net/twiki/bin/view/IVOA/CSPTimeSeries][CSP Time Series use cases]]*)

   * use cases
   * ideas for solutions
   * attempts and prototypes reports

---+++ Functionalities

   * Feedback : what is missing/inadequate in current protocols
   * Extended metadata (for Cubes and Time Domain)
   * Extended server side data services (regridding, deconvolution, etc.)

---+++ Software Design

---+++++ Interface design

   * Feedback on current interfaces
_Recently I discovered that calls to datalink+SODA, outside ObsCore and SIAv2 context are available in VizieR, but also in GAVO. Markus is now using in SIA 1.0 responses (see http://dc.zah.uni-heidelberg.de/lswscans/res/positions/siap/siap.xml?POS=311.41098458333335,30.723715361111108&SIZE=2.64&FORMAT=image/fits) It sounds reasonable and I can imagine we wil find more of that in the future. But here there are already fields with utypes Access.Reference in le SIA mai n part, it is now difficult/impossible to recognize that a given link will return Datalink or something else._

_On the other side, the Datalink VOTable response doesn't contain any signature allowing to recognize a posteriori that it has a datalink content. That's a pity. This would have been harmless and could simplify everything._

_This has direct consequence on Aladin v10 (or any other client), which has the code necessary to perform specific actions for DataLink., cannot benefit from all these standardisation efforts and is limited to display the DataLink result as a simple,VOTable without coordinates , or still worse in a Web navigator._

_The good point is that we are now close to a real usage and no more in prototyping. THis kind of usage is probably wider than what was imagined initially for datalink Aladin is close to make something of it there is now a couple of servers which deliver these things. JUST sad that everybody is using it his own way with the consequency that it remains unusable, while nearly nothing is missing to fix that._

_So, I would recommend two changes:_

_-A simple method to identify the links and to discover what they are supposed to return_

_solution 1: a specific utype for datalink URL (ex: utype=Access.Reference.Datalink.1.xxx")_

_solution 2: an appropriate LINK in the FIELD definition (ex: LINK content-type="application-stream/votable;datalink" ...)_

_-A signature in the VOTable, for example using an INFO tag or as an attribute of RESOURCE , RESOURCE type="result;datalink"..._

_These "solutions" are just examples to illustrate the idea. WE have to check their validity with regard with the standard evolution. -- IVOA.PierreFernique - 2017-03-07_

   * Driving extended functionalities
_Current DAL situation for dataset discovery and access_

We have a core of 4 protocols SIAV2, ObsTAP, DataLink and SODA ?

ObsTAP is controled via ADQL and its response is an Obscore table. SIAV2 is a parameter driven service, doesn't requite TAP infrastructure . In some respects it is a PQL ObsTAP (actually parameter language allows more evolution towards virtual data)

DataSets can be searched by any of the Spatial, time, band and polarization criteria.

Access is managed by SODA / currently only doing cutouts on ND cubes.

DataLink provides gluing facility between all these protocols responses and with other services

_Older protocol "lost "functionalities_

SSA allows to discover spectra by Spatial and BAND positions / response in discovery mo

de standardized with SSA response (some kind of pre-Obscore)

SIAV1.0 allows to discover anything with a 2D signature on space, but only Spatial axes are standardized.

SSA and mostly SIAV1 have a "virtual data discovery mode" IN that case the retrieval is performing "Server side operations for data access"

_Possible evolution to extend the functionalities of the new protocol and tackle the TimeSeries CSP priority_

SIAV2 interface could allow discovery of TimeSeries and Spectra with little extensions (time frequencies characterisation for example) Some functionalities available in SSA/SIAV1.0 have to be added to SIAV2

Virtual data discovery : Basically the service arbitrates the discovery query parameters and propose a matching SODA URL. Specially usefull for TimeSeries where many time the TimeSeries is built from the data content.

We could extend the parameters in ObsCore to tackle TimeSeries and spectra, add input paramaters to constrain that and add virtual data functionality

This will be both an extension of SIAV2.0 and a new overall "DataSet discovery" protocol.

SODA = add spectra and Time Series functionalities

Provide Extended metadata consistent with NDcube DM : is this a work for SIAV2 or for SODA 1.1 ?
Extended metadata retrieval (any kind of full serialization of datamodels for a given dataproductype) is very close to retrieval of the dataset themselves (or excerpt/transformations of datasets). So it seems that this functionnality is more a SODA one than SIAV2 one...  

-- IVOA.FrancoisBonnarel - 2017-05-15

   * Standard definition of custom services
Full knowledge of custom services is in the hands of these custom services developpers !!! Currently service descriptors are in the hands of data centers operating DAL discovery and/or DataLink services.

_They may not know all the details on the service parameters_

_DataLink service operfors may not know the dataset metadata in detail_

It could be usefull to add in DataLink the feature that services autodescribe

-- IVOA.FrancoisBonnarel - 2017-05-15

---+++++ Pushing code to the data

   * Science cases
   * Attempts and prototypes

---+++++ Formats and Languages

   * Json, !PQL, PDL, etc.
   * What to use next ?

---+++ TAP evolution

   * From relational databases to...
   * Relaxing !ADQL ?

---+++ TAP & Healpix

_[This part is a sum-up of the talk <span style="background-color: #ffffff;"><a target="_blank" href="http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-DAL/mantelet_tap-moc.pdf">Bringing Healpix and MOC in TAP</a></span> by G. Mantelet presented at the IVOA Interoperability meeting in May 2017 in Shanghai.]_

In TAP, with few extensions, it could be possible to get Healpix information <span style="background-color: transparent;">and/or to add constraints on Healpix information.</span>

<span style="background-color: transparent;"> *Proposed new features:* </span>

   * New UDFs: 
      * ivo_healpix_index(hpx_order INTEGER, position POINT) --&gt; BIGINT
      * <em> <span style="color: darkgray;" class="WYSIWYG_COLOR"><span style="color: dimgray;" class="WYSIWYG_COLOR">ivo_healpix_index(hpx_order INTEGER, ra DOUBLE, dec DOUBLE) --&gt; BIGINT </span></span></em><em><span style="color: darkgray;" class="WYSIWYG_COLOR"><span style="color: dimgray;" class="WYSIWYG_COLOR">[optional]</span></span></em>
      * <em> <span style="color: dimgray;" class="WYSIWYG_COLOR">ivo_healpix_center(hpx_order INTEGER, hpx_index BIGINT) --&gt; POINT </span><span style="color: darkgray;" class="WYSIWYG_COLOR"><span style="color: dimgray;" class="WYSIWYG_COLOR">[optional]</span></span></em>
      * moc_agg(hpx_order INTEGER, position POINT) --&gt; MOC
      * <span style="color: slategray;" class="WYSIWYG_COLOR"><span style="color: lightslategray;" class="WYSIWYG_COLOR"><span style="color: dimgray;" class="WYSIWYG_COLOR"><em>moc_agg(hpx_order INTEGER, hpx_index BIGINT) --&gt; MOC </em></span></span></span><em><span style="color: darkgray;" class="WYSIWYG_COLOR"><span style="color: dimgray;" class="WYSIWYG_COLOR">[optional]</span></span></em>
   * Addition of the geometrical type 'MOC' in DALI (in addition of the already existing POINT and REGION) 
      * in VOTable: &lt;FIELD ... datatype="char" arraysize="*" *xtype="MOC"* /&gt;
      * a MOC would be serialized into an ASCII representation described in the appendices of the talk <a target="_blank" href="http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-DAL/mantelet_tap-moc.pdf">Bringing Healpix and MOC in TAP</a>. _*Example:* "10/63-65,87 11/1 13/" (i.e. MOC of order 13 with 4 cells at order 10 and one cell at order 11)_
      * using this ASCII serialization, it could be possible to create manually a MOC using the function REGION(...). _*Example:* "REGION('1/1,3,4 2/4,25,12-14,21')"_
   * The ADQL grammar of some geometrical functions (like AREA, CONTAINS and INTERSECTS) should be adapted in order to be able to operate on any function returning geometrical regions. For the moment, it is limited to POINT, BOX, CIRCLE, POLYGON and REGION. This does not allow the usage of UDFs returning region, like moc_agg(...) as defined above or REGION(...) with an ASCII representation of a MOC.
*Still to answer:*

   * How to designate an Healpix-related value (e.g. Hpx index, MOC) in a VOTable? 
      * UCD? Datatype? XType _(xtype='MOC', ok but what about an Hpx index: xtype='HEALPIX'?)_ Or more complex like a VOTable GROUP?
      * An Healpix index or derived product always requires 2 additional pieces of information: _scheme_ ('nested' or 'ring') and _order_ (an integer between 0 and 29). How to provide them along the Healpix-related value in a VOTable?
*Usage examples:*

   * 2-D histogram using Healpix <em>(see </em><a target="_blank" href="http://www.star.bris.ac.uk/~mbt/papers/adassXXVI-P1-31-poster.pdf"><em>ADASS Poster</em></a><span style="background-color: transparent;"><em> for more examples)</em>:</span>
<pre style="padding-left: 60px;"><verbatim>SELECT ivo_healpix_index(7, POINT(’’, ra, dec)) AS hpx_index, COUNT(*) AS density
FROM tycho2
GROUP BY hpx_index</verbatim>
</pre>

   * creating a MOC at Healpix order 7 from Tycho2 (or a subset):

<verbatim style="padding-left: 60px;">SELECT moc_agg(7, POINT(’’, ra, dec)) AS mymoc
FROM tycho2
...</verbatim>

   * filtering by Healpix index:

<verbatim style="padding-left: 60px;">SELECT *
FROM tycho2
WHERE ivo_healpix_index(7, POINT(’’, ra, dec)) IN (12,23,68,69,70)</verbatim>

   * filtering by MOC: 
      * with an ASCII serialization:

<verbatim style="padding-left: 90px;">SELECT *
FROM tycho2
WHERE 1= CONTAINS(POINT(’’, ra, dec), REGION(’2/12-20 5/60’))</verbatim>

   * 
      * with a MOC embedded in a VOTable column (or more):

<verbatim style="padding-left: 90px;">SELECT t.*
FROM tycho2 AS t JOIN TAP_UPLOAD.mymoc AS m
ON 1=CONTAINS(POINT(’’, t.ra, t.dec), m.moc1)</verbatim>

<em>TAP_UPLOAD.mymoc is a normal uploaded VOTable table with a column named <span style="background-color: transparent;">moc1 of type &lsquo;VARCHAR&rsquo; and xtype 'MOC'.</span></em>

   * 
      * with a MOC formatted into a binary FITS table:

<verbatim style="padding-left: 90px;">SELECT t.*
FROM tycho2 AS t JOIN TAP_UPLOAD.mymoc AS m
ON 1=CONTAINS(POINT(’’, t.ra, t.dec), m.moc)</verbatim>

<em>Instead of uploading a VOTable, a FITS file would be uploaded (the TAP <span style="background-color: transparent;">implementation has to allow that). The uploaded FITS file has special </span><span style="background-color: transparent;">headers specifying that it represents neither an image nor a table, but a </span><span style="background-color: transparent;">MOC. Then, it should be considered as such while used in the ADQL query. </span><span style="background-color: transparent;">But TAP allows only the upload of table. So, in order to use the uploaded </span><span style="background-color: transparent;">MOC, the TAP service has to create a table of only one cell containing the </span><span style="background-color: transparent;">uploaded MOC (so, one cell for the entire FITS file). As for a "normal" </span><span style="background-color: transparent;">upload, the name of the table is provided in the HTTP parameter UPLOAD, </span><span style="background-color: transparent;">but there is no name for the column containing the single MOC and that </span><span style="background-color: transparent;">we need to refer to in the ADQL query. To solve this issue, we could agree </span><span style="background-color: transparent;">on a standard name for this column: let's say "moc". So, on the above </span><span style="background-color: transparent;">example we had UPLOAD="mymoc,param:moc.fits" which has been uploaded as </span><span style="background-color: transparent;">the table TAP_UPLOAD.mymoc with only row and one column named "moc".</span></em>

<span style="background-color: transparent;">-- IVOA.GregoryMantelet - 2017-05-29</span>
---+++ Position in IVOA landscape

---+++++ Merging DAL protocols, !HiPS and MOC

   * !HiPS is also a discovery and access mode: How to marry service approach and !HiPS Approach in both ways ?
   * Querying services by MOC : is that necessary ?

---+++++ Data Models

   * !ObsCore
   * !DataSet Metadata
   * ND-Cube
   * !SparseCube
   * !STC
   * other...

---+++++ Updating SCS

SCS still requires VOTable 1.1 and has some other quirks that makes it needlessly incompatible with the rest of the DAL landscape (in particular, it's totally DALI-incompatible). We should figure out how we can evolve it to be less odd with minimal disruption to existing services and clients (e.g., relaxing VOTable requirements, support for DALI MAXREC, RESPONSEFORMAT, metadata discovery). -- IVOA.MarkusDemleitner - 2017-03-01

In SCS there are three things which are causing problems for me:

1) The UCD's that are required by the spec are rather outdated. 2) VOTable is required to be 1.0 or 1.1, which is far behind the current 1.3. 3) It requires a column with ucd="ID_MAIN". In UCD1+, this would be meta.id. We do not always have a column with that ucd, but we do have one with ucd=meta.record. So I would propose that the table must have one of meta.id or meta.record.

-- IVOA.WalterLandry - 2017-04-15
<div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste"> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">In TAP, with few extensions, it could be possible to get Healpix information</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">and/or to add constraints on Healpix information.</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">Proposed new features:</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- New UDFs:</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- ivo_healpix_index(hpx_order INTEGER, position POINT) --&gt; BIGINT</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- ivo_healpix_index(hpx_order INTEGER, ra DOUBLE, dec DOUBLE) --&gt; BIGINT</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- ivo_healpix_center(hpx_order INTEGER, hpx_index BIGINT) --&gt; POINT</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- moc_agg(hpx_order INTEGER, position POINT) --&gt; MOC</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- moc_agg(hpx_order INTEGER, hpx_index BIGINT) --&gt; MOC</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- Addition of the geometrical type 'MOC' in DALI (in addition of the already</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">existing POINT and REGION)</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- in VOTable: &lt;FIELD ... datatype="char" arraysize="*" xtype="MOC" /&gt;</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- a MOC would be serialized into an ASCII representation described in the</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">appendices of the talk</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">[Bringing Healpix capability in TAP][http://....].</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">Example: "10/63-65,87 11/1 13/" (i.e. MOC of order 13 with 4 cells at</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">order 10 and one cell at order 11)</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- using this ASCII serialization, it could be possible to create manually</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">a MOC using the function REGION(...).</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">Example: "REGION('1/1,3,4 2/4,25,12-14,21')"</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- The ADQL grammar of some geometrical functions (like AREA, CONTAINS and</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">INTERSECTS) should be adapted in order to be able to operate on any</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">function returning geometrical regions. For the moment, it is limited to</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">POINT, BOX, CIRCLE, POLYGON and REGION. This does not allow the usage</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">of UDFs returning region, like moc_agg(...) as defined above or REGION(...)</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">with an ASCII representation of a MOC.</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">Still to answer:</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- How to designate an Healpix-related value (e.g. Hpx index, MOC) in a VOTable?</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- UCD? Datatype? XType (xtype='MOC', ok but what about an Hpx index: xtype='HEALPIX'?) Or more complex a VOTable GROUP?</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- An Healpix index or derived product always requires 2 additional pieces of</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">information: scheme ('nested' or 'ring') and order (an integer between 0 and 29).</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">How to provide them along to the Healpix-related value in a VOTable?</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">Usage examples:</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- 2-D histogram using Healpix (see http://www.star.bris.ac.uk/~mbt/papers/adassXXVI-P1-31-poster.pdf for more examples):</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">SELECT ivo_healpix_index(7, POINT(&rsquo;&rsquo;, ra, dec)) AS hpx_index,</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">COUNT(*) AS density</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">FROM tycho2</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">GROUP BY hpx_index</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- creating a MOC at Healpix order 7 from Tycho2 (or a subset):</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">SELECT moc_agg(7, POINT(&rsquo;&rsquo;, ra, dec)) AS mymoc</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">FROM tycho2</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">...</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- filtering by Healpix index:</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">SELECT *</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">FROM tycho2</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">WHERE ivo_healpix_index(7, POINT(&rsquo;&rsquo;, ra, dec)) IN (12,23,68,69,70)</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- filtering by MOC:</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- with an ASCII serialization:</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">SELECT *</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">FROM tycho2</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">WHERE 1= CONTAINS(POINT(&rsquo;&rsquo;, ra, dec), REGION(&rsquo;2/12-20 5/60&rsquo;))</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- with a MOC embedded in a VOTable column (or more):</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">SELECT t.*</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">FROM tycho2 AS t JOIN TAP_UPLOAD.mymoc AS m</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">ON 1=CONTAINS(POINT(&rsquo;&rsquo;, t.ra, t.dec), m.moc1)</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">TAP_UPLOAD.mymoc is a normal uploaded VOTable table with a column named</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">moc1 of type &lsquo;VARCHAR&rsquo; and xtype 'MOC'.</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">- with a MOC formatted into a binary FITS table:</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">SELECT t.*</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">FROM tycho2 AS t JOIN TAP_UPLOAD.mymoc AS m</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">ON 1=CONTAINS(POINT(&rsquo;&rsquo;, t.ra, t.dec), m.moc)</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">Instead of uploading a VOTable, a FITS file would be uploaded (the TAP</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">implementation has to allow that). The uploaded FITS file has special</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">headers specifying that it represents neither an image nor a table, but a</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">MOC. Then, it should be considered as such while used in the ADQL query.</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">But TAP allows only the upload of table. So, in order to use the uploaded</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">MOC, the TAP service has to create a table of only one cell containing the</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">uploaded MOC (so, one cell for the entire FITS file). As for a "normal"</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">upload, the name of the table is provided in the HTTP parameter UPLOAD,</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">but there is no name for the column containing the single MOC and that</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">we need to refer to in the ADQL query. To solve this issue, we could agree</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">on a standard name for this column: let's say "moc". So, on the above</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">example we had UPLOAD="mymoc,param:moc.fits" which has been uploaded as</div> <div style="position: absolute; left: -10000px; top: 2226px; width: 1px; height: 1px; overflow: hidden;" id="_mcePaste">the table TAP_UPLOAD.mymoc with only row and one column named "moc".</div> </div>
This topic: IVOA > WebHome > WebPreferences > DALFuture
Topic revision: r10 - 2017-05-30 - FrancoisBonnarel