content, format, ctype, or xtype ?

[Douglas Tody]

On Fri, 15 May 2009, Arnold Rots wrote:

> To answer you last comment: I wasn't specifying how the query should
> be phrased, only the content. Btw, remind me: SIZE is in angular
> units, right, not in coordinate units? In which case POS,SIZE wouldn't
> work.

POS is a single point in the specific coordinate frame (limited by
whatever the service supports, defaulting to ICRS).  SIZE is an angular
measure relative to the central position, hence is independent of
the frame (in other words POS,SIZE in TAP is a cone search).  If we
try to take the final region and transform it to another frame then
as you say that could get complicated.

> I don't disagree with Tom. My concern was that servers would implement
> common non-ICRS queries correctly and efficiently. That concern was
> fed by a service I once saw that transformed the corners of such an
> (l,b) query to (RA,Dec) and then performed the query on max and min of
> those coordinates :-(

You can be sure that there will be services which continue to do
this sort of thing!  The big data centers can handle it (and have to
or they will quickly be found out).  For the smaller data providers
we need service frameworks and toolkits, it is the only hope to get
robust services.

 	- Doug


>  - Arnold
>
>
> Douglas Tody wrote:
>> On Fri, 15 May 2009, Tom McGlynn wrote:
>>>
>>> The question that I think we should be posing is what capabilities do we
>>> provide the user in querying the system and in seeing the results.  The
>>> internals of how one site stores things internally is something that we might
>>> chat about, but I don't see that it should be mandated or even discussed in
>>> the standard.
>>
>> Whether data providers do this by adding new columns or by adopting
>> the guidelines when a table is first created should be up to the
>> data provider.  Most would probably choose to add columns in the case
>> of old tables, but they might also adopt the guidelines directly
>> when designing new tables.  Whether they compute the data on the
>> fly or store the data directly in the tables does not matter, that
>> is a back-end implementation issue.  Compliance should be optional
>> but recommended.
>>
>>> Arnold Rots wrote:
>>>> Here is the issue:
>>>> If a user queries a catalog for, say 90 < l <270 AND -30 < b < 30
>>>> you have to do an on-the-fly transformation of almost all your RA,Dec
>>>> entries in order to make sure you get the right subset.
>>
>> Why not just do this properly with a TAP spatial query (POS,SIZE,
>> REGION, etc.).  This is simple for the client.  What happens on the
>> server side is up to the service.  It will eventually come to proper
>> spatial indexing and careful coordinate transformations on the server
>> side, if we try to do very much with such spatial queries.
>>
>>  	- Doug
>>
> --------------------------------------------------------------------------
> Arnold H. Rots                                Chandra X-ray Science Center
> Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
> 60 Garden Street, MS 67                              fax:  +1 617 495 7356
> Cambridge, MA 02138                             arots at head.cfa.harvard.edu
> USA                                     http://hea-www.harvard.edu/~arots/
> --------------------------------------------------------------------------
>