Multi-dimensional Data Access minimal requirements

[Patrick Dowler]

Note: *not* cross-posting to DM list.

On 07/03/14 10:58 AM, Ray Plante wrote:
> Hi Severin et al,
>
> I think this is a good set of minimum requirements, and appears to be
> consistent with what we're doing in the VAO.  I have two comments:
> first,
>
> On Thu, 6 Mar 2014, Gaudet, Severin wrote:
>>   *  Simple Cutout
>>       +  For a simple cutout, the user-specified subset is restricted to be a
>>          contiguous interval within each dimension of the multi-dimensional
>>          science data. The user should *not* be allowed to specify subsets
>>          with "gaps" or resampling or anything like that.
>>           o  Spatial: a circle (a coordinate and a radius)
>
> I suspect this is a typo or mistake.  Are really saying users would
> request a spatial cutout, which comes back as a rectangular array,
> using a circle?  A rectangle specified like the SIA query would do,
> and I'm betting is what you meant.

"circle' is not a typo. The user would specify a circular region of 
interest and the service would return a rectangular array that includes 
that circle. The use of a circle avoids anyone assuming that any 
rotation would be applied. If the client specifies range of coordinates 
or a polygon, we would have to be more clear in documentation exactly 
how those were supposed to be treated as they do carry orientation 
information. Basically, circle has no orientation so it never implies 
anything and is the simplest region-of-interest to deal with.

See below for more on this.

> The second comment is a request: this would be a good time to get a
> snapshot of where the three documents are.  DataLink, of course, is
> quite mature and the latest version is in circulation.  Could we get a
> posting of the SIAv2, ImageDM, AccessData drafts posted to the DAL
> twiki asap?  (The last available SIAv2 is in the doc repos, dated
> 15-nov; is there something newer out there?)

Yes, WD-DataLink was just posted and is in good shape. The remaining 
issues are known and highlighted within the document.

The WD-SIA-2.0 from November has been discussed on the list; query 
params seems to be acceptable, but the use cases call for two more query 
parameters. I will be posting something to the list today on that. A new 
revision would be done when these extra params are decided, and when the 
upload topic (see DAL list) comes to some resolution.

I have a WD-AccessData-1.0 document written (never posted) that has 
enough to satisfy the simple cutouts. I will post something on that 
topic as well and could post the document within the next week. I have 
in general been going for targetted mailing list discussion, editorial 
work, and teh a new WD to the doc repository rather than partial docs on 
the wiki pages. I think it works better once we are past the 
brain-storming stage.

For cutouts, the parameters I have are essentially the same as the 
WD-SIA-2.0 basic query parameters (POS, BAND, TIME, POL): they specify a 
region of interest. The difference is that one capability (and REQUEST 
value) specifies searching for data and the other cutout from a single 
selected dataset.

* First : we could specify spatial cutout using circle, coordinate 
range, and polygon with no extra effort (in fact, it is written already 
and the same as SIA query).

* Second: this allows one to implement a single web resource that 
provides both query and cutout (differing in REQUEST value only) while 
others can implement query at one URL and cutout at a different URL (as 
required by their storage/delivery infrastructure). This came up in 
previous discussions about the apparent redundancy of defining REQUEST 
for a capability with only one value, but this is the reason: 
implementation flexibility. Services also get to describe what they can 
do in VOSI-capabilities and the two capabiliies can (in future) evolve 
without opening up larger more complex documents.

Summary: WD-AccessData-1.0 doesn't have anything in it that will be at 
all new or unfamiliar to anyone; just another small and easily grok'ed 
document describing one capability, with an easy transition to 1.x :)

The only thing that needs clarifying in AccessData is the same thing 
that I recently changed in DataLink: make it clear that the capability 
can be embedded with other capabilites in a single larger service. This 
is allowed, just not clear from the way the VOSI-capabilities section is 
written (which implies stand-alone service). I can have that document 
out early next week.

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)