POL (Re: About the draft itself Re: WD-SIA-2.0)

[Douglas Tody]

We agreed quite some time back to support multiple parameter instances
at the HTTP level (POL=I&POL=Q etc.) since this is how HTTP works and
sometimes it is more convenient to do it that way.  However that does
*not* mean that a list-structured value cannot also be supported for a
parameter.  In fact it is quite easy to support both, and we will need
to do so for quite some time, e.g., for SSA V1.1 services.  List values
are natural for many use cases, not just POL.

> The first was essentially an adhoc decision; the second comes from previous 
> use in DAL services and is based on some external param-based query spec 
> (can't recall, was in geoscience, iirc) where / was used because it is

I don't think much of the use of / for polarization state lists in
ObsTAP myself, but the use of "/" for ranges comes from ISO8601, where
time ranges use the / character.  It also tends to work well with less
interference with things like numbers, where other range separators like
":" and "-" get into trouble.

Anyway for POL, supporting syntax like POL=I,Q,U,V is clearly the most
natural way to do it from a human user point of view.  The full list of
polarization states supported is as defined in FITS WCS according to the
ObsTAP specification (B.6.6 pg 46).  That means that states like LL, RR
need to be supported as well.

 	- Doug


On Tue, 6 May 2014, Patrick Dowler wrote:

>
> On 14/04/14 01:00 PM, Arnold Rots wrote:
>> Since polarization is an enumerated axis, I think POL=I,Q,U,V should be
>> perfectly acceptable, but POL=I/V is not.
>> Note that by explicitly endorsing Stokes parameters, other polarization
>> expressions (circular, linear, vector) are excluded.
>
> Querying the polarization axis for (ObsCore) pol_states that are present in 
> the data is not straightforward.
>
> Using repeated parameters (as is done when you pick multiple things from a 
> picklist), eg:
>
> POL=I
> POL=Q
> POL=U
>
> would generally mean that the data has to contain at least one of these. 
> Changing that behaviour is wide-reaching and DAL has long ago (Nara, iirc) 
> decided to use this in place of comma-separated lists for multiple input 
> values. Using a range construct, eg:
>
> POL=I/U
>
> would mean the same thing and find the same data (in this particular example 
> but not for all). In a TAP+ADQL query of the ObsCore table, one could look 
> for exactly IQUV with
>
> pol_states like '/I/Q/U/V/%'
>
> as described in ObsCore-1.0 B.6.6 (no wildcard at front because I is first in 
> the canonical ordering). That would do what people want, leading me to think 
> that
>
> POL=I Q U V
>
> (suitably separated and/or encoded) is the right way to say "search for data 
> with all of these states".
>
> Now the mess: ObsCore-1.0 says that the separator between pol_state values is 
> the slash (/) character and range querying in DAL also uses the / character. 
> The first was essentially an adhoc decision; the second comes from previous 
> use in DAL services and is based on some external param-based query spec 
> (can't recall, was in geoscience, iirc) where / was used because it is 
> straightforward to split  and doesn't interfere with scientific notation, 
> ISO8601 timestamp values, etc.
>
> Technically, the ADQL constraint would be: pol_states like '/I/Q/U/V%' and 
> the POL parameter cannot use that string.
>
> So, is searching for exactly I Q U V easily supported in the POL parameter? 
> If in a single parameter, what separator? Is that a general pattern for other 
> enumerated fields (personally: I doubt it: I have not run into another 
> enumerated field with multiple values like pol_states)
>
>
> PS - In my opinion, any special treatment means we are in for some complex 
> language and a single very peculiar parameter if we try to support this. I 
> think we should stick with multiple values and ranges and if someone needs 
> more explicit query capability they can/should use TAP, where the hard and 
> general problems are dealt with.
>
> -- 
>
> 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)
>