[SIAv2] query params

[Douglas Tody]

Apologies for taking so long to comment; I am working from home
nursing a cold this week.

The proposal here appears to be that POS,SIZE,BAND,TIME,POL, and in
particular POS, could be generalized sufficiently so that we can drop
the REGION parameter (REGION being an STC-S string that an optionally
replace POS,SIZE,BAND,TIME,POL as the specify the filter term).  I will
ignore the issue of REGION for the moment, but agree strongly that
having things already broken out as in POS,SIZE,BAND,TIME,POL makes
service implementation simpler, and extends well to capabilities such as
range-list values.

It is nice to see that the current interface is not completely
abandoned.  This approach looks like it could work for spatial queries,
and is more general than the old POS,SIZE for this function, but it is
not clear if it supports automated cutout generation / filtering, where
POS,SIZE specifies the ideal image footprint for the generated image.
Maybe so; it is possible that RANGE could serve the same purpose.  But
automated virtual data generation is an important capability that must
not be lost.  Just having accessData alone is not the same thing, as
this can only work on a single dataset at a time and may require
preknowledge of the image metadata.

In response the comment that a box or range region blows up at the
poles, I'll just note the original draft SIAV2 spec specifies POS,SIZE
when used for simple discovery as a 2D cone search.  This is based upon
angular distance on the sky hence, like a conventional 1D cone search,
hence there is no issue.

Re RANGE, support for open and closed ranges as well as range lists and
simple lists (as already specified in the current draft and in SSA) is a
key interface capability required for a parameter-based interface.  This
should not be limited to POS; it is needed for BAND, TIME, POL as well
and sometimes other parameters.  So for example open ranges may be used
to specify less-than and greater-than, while a closed range specifies a
range from A to B.  A single value can be considered a degenerate case
of a range specifing a point value.  A simple list is a special case of
a list of single values.

My opinion is that it would be nice to build upon the current syntax
since it does all these things and is already in use and implemented.
Improvements are possible, e.g., replacing the comma delimiter with a
space might be possible and could improve readability.

As you noted, the "/" character is already used in ISO time values to
specify a range, and it is about as good or better a choice for ranges
as anything else (:- etc. have their issues), so it is a logical choice
for the range delimiter here as well.

 	- Doug


On Tue, 12 Nov 2013, Patrick Dowler wrote:
> I have been working on the query parameter section of the SIAv2 document and 
> seeing how it relates to the initial cutout spec in the AccessData document.
>
> ** Reminder:
>
> SIAv1 and previous SIAv2 drafts have included POS and SIZE for spatial 
> queries, interpreted as a box.
>
> Spatial querying in TAP+ADQL packs the spatial query stuff into a single 
> predicate with functions like POINT, CIRCLE, BOX, and POLYGON for "spherical 
> geometry values". The cutout prototype that CADC showed packed all the 
> spatial stuff into an STC-S string. We have discussed the pros and cons of 
> this and it seemed pretty clear that people generally found the inclusion of 
> coordsys metadata in the ADQL functions and the passing of STC-S strings to 
> be problematic: if the service can and does perform coordsys transformations, 
> then it is a nice piece of magic... if they can't do it (for whatever input 
> values they receive) then it is another way to fail. We certainly would need 
> *and do not have* a way to describe which coordsys values are supported by 
> services. In Hawaii, I think we concluded that in future we should *not* 
> include coordsys metadata with the values (eg STC-S) in parameter values nor 
> in the table data portion of results -- the coordsys metadata belongs with 
> the metadata (e.g. in the header portion of a VOTable or other such 
> container). We also agreed that some plain "spherical geometry" values need 
> to be supported.
>
> side note: My personal view is that this reasoning also applies very 
> correctly to those ADQL region functions and datatypes/output values and a 
> future version should address that.
>
> ** Proposal for SIAv2 query params:
>
> * use a single POS parameter for the spatial axis query (symmetric with BAND, 
> TIME, and POL parameters/axes) with a naked geometry value
>
> * define naked geometry value syntax, which is like STC but with no metadata:
>
> CIRCLE <long> <lat> <radius>
> POLYGON <long1> <lat1> <long2> <lat2> ...
>
> an instead of the BOX (from STC) that is somewhat complex to do correctly, I 
> propose:
>
> RANGE <long1>/<long2> <lat1>/<lat2>
>
> which uses the range syntax supported by the BAND and TIME parameters.
>
> So, a "conesearch" kind of query is POS=CIRCLE 12 34 0.5, for example.
>
> This would make SIZE obsolete (in the multi-dimensional world, it is 
> semantically ambiguous) and I this whole line of reasoning would kick 
> REGION=<STC-S string> out entirely.
>
> The result is that SIAv2 query parameters would be POS, BAND, TIME, and POL 
> (plus I heard arguments about the redshift axis needing a REDSHIFT param).
>
> The actual syntax (separators between terms/numbers is TBD, and I know there 
> have also been differences of opinion abut the range syntax with /) but 
> Daniel Durand and I wrote a bunch of examples on my whiteboard and it looks 
> very simple and comprehensible (including using the range syntax within the 
> POS=RANGE ... construct).
>
>
> Comments?
>
>
> -- 
>
> Patrick Dowler
> Canadian Astronomy Data Centre
> National Research Council Canada
> 5071 West Saanich Road
> Victoria, BC V9A 2L9
>
> 250-363-0044 (office) 250-363-0045 (fax)
>