SODA-1.0 cumulative"> SIAP-2.0 and SODA-1.0 cumulative "-Next" page.
| ||||||||
Changed: | ||||||||
< < | SIAP-2.0 feedback, issues and proposals | |||||||
> > | SIAP-2.0 feedback, issues and proposals (status in May 2020) | |||||||
On GitHub: https://github.com/ivoa-std/SIA | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Several SIAP2.0 parameters have a limited list of possible values – Some have lists limited by protocol (and obscore) POL (Stokes, LINEAR, etc..) DPTYPE (image, cube, visibility, timeseries ;..) CALIB : levels FORMAT : fts, jpeg , png, etc.. – Some have free string values COLLECTION (HST, WISE, etc...), FACILITY (VLT, Keck, Chandra), INSTRUMENT (ACS, MEGACAM, etc.) – PARAMETERs less useful if we have no prior idea of their possible values. It often happens that services do not provide these lists of parameters although section 2.1.1 However Section 2.1.20 of SIAP2.0 states : Service PARAMETER self description Any service may include a DataLink service descriptor in the vOTable output to describe itself. this descriptor would describe the supported query parameters (standard and custom) including list of values for those with a fixed list (eg. COLLECTION INSTRUMENT FACILITY DPTYPE CALIB and FORMAT) * This will allow to discover "possibilities" of the service prior to usage and optimize the queries The "MAY" is obviously too weak. Version 2.1 could state SHOULD or MUST | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
ObsCore has an optional parameter "obs_release_date", but some projects complain no SIA PARAMETER allows to select on this. Solution : create an OPTIONAL parameter to select on that ? What is the policy for OPTIONAL parameters ? | ||||||||
Added: | ||||||||
> > | Done with https://github.com/ivoa-std/SIA/pull/16 . Merged in may 2022. (FrancoisBonnarel - 2023-05-31) | |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
What is the price to pay to allow case-insensitive and how do we do that ? | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
The spec clearly states that RA is in [0,360] and DEC is in [-90,90] but some POS=RANGE ... examples use -Inf and +Inf (probably copied the idea from use of open ended intervals in other params). I consider this a bug in the example that should result in a fix and erratum because I recall we explicitly decided to not have services doing range reduction. | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
SIAP1 had « cut out » and « mosaic » modes besides « archive » mode → 1 shot before access but only spatial We now have : SIAP2.0 or ObsTAP which deal with all axes SODA : for cutouts only (all axes) +DataLink (Service descriptor and/or {links} table) → 2 shots before access (instead of 1) Although it is pretty useful to have the 2 shots sometimes (allow the user to choose the actual limits according to ObsCore content and general context) there have been some complains (SkyView people for example also others) that the one-shot functionality disappeared. It would be perfectly possible to provide it by replacing the full retrieval or datalink url in access_url by a SODA url. SODA URL parameters are common with SIA. Where SIA Parameters values constrain the discovery, SODA parameters force the cutout dimensions. A capability "virtual data generation" would have to be added to the service. If it exists how do we choose to provide these cutouts by a new "VIRTUAL" boolean parameter? Or by providing two lines in the response with the same obs_id ? The obscore values will be different, encluding publisher_did, but the observation will be the same | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Alberto Micol 2019/03/&4 : SIA specifies: "The FORMAT parameter specifies response format(s) (the access_format column from the ObsCore [7] data model). This column describes the format of the response from the access_url (see 3.1.3) so the values could be data file types (e.g. application/fits) or they could be the DataLink [8] MIME type." The initial part of the sentence mentions "response format(s)", which that greatly overlaps, and generates confusion (at least in my mind), with the following DALI specification: "The RESPONSEFORMAT parameter is used so the client can specify the format of the response (e.g. the output of the job)." The SIA FORMAT and the DALI RESPONSEFORMAT are two different things, and I think that should be better clarified in the text of the next SIA version. Could that be done? | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Extending VIrtual SIAP2 as described in issue re-gridding/rebinning along a specific WCS can be done by adding this functionality to the virtual data discovery functionality described in issue #6. The access URL would be a SODA URL with the additional parameters proposed in SODA issue #4 An alternative is allowing SIA1 parameters of the MOSAIC mode to SIA2 interface | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
MOC (as well as STMOC, and maybe STEMOC) has proven to be a very efficient way to describe coverage of data and is used for discovery of data. It has been often discussed and also during last interop that it should be useful to query SIA services by MOC ? It should probably be with a new parameter and not via POS considering that it is probably more useful to have STMOC or STEMOC, than spatial MOC alone. This is also valid for SODA of course (SODA Issue #5). I wonder if this new parameter should not be standardized by DALI | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
There was a demand to be able to use a parameter based interface "à la" SIAP2 for other dataproduct_types than cube and image
DPTYPE constraint should be relaxed
eg: measurements
time-series
etc....
CADC actually created a service like this.
What could be the name? SIA is no more appropriate
For time-series this has been discussed in the following ivoa note: http://www.ivoa.net/documents/Notes/TimeSeriesDiscoveryAndAccess/index.html
For some dataproduct_types a specific ObsCOre extension may be needed; For TimeSeries this was discussed in recent past. see for example:
https://wiki.ivoa.net/internal/IVOA/InterOpOct2017TDIG/IVOA2017Santiago-DiscussionTDIG-DM-DAL-Session1.pdf
or
http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/TSSerializationNote.pdf
SODA-1.0 feedback, issues and proposalsOn GitHub: https://github.com/ivoa-std/SODA
<--
|