[SIAv2] query params

[Patrick Dowler]

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)