do something useful and simple first

[Roy Williams]

Ray

Yes, OpenSkyQuery is excellent for crossmatch. However, I maintain that 
what you can do there can be done easily as a two-stage process: first 
do multicone for the rough crossmatch, then download the result to the 
desktop and refine the result with further selections, using 
Topcat/Stilts. So multicone gives us the ability to do crossmatch, and 
of course we can do single-catalog query with existing facilities (eg 
Vizier). What else is there? What are the "many capabilities" you 
mention below?

There are already many versions of multicone out there (*). It is mainly 
a rather simple question of standard formatting for the upload table 
(RA,Dec,ID,radius for each). The version 2 standard could handle 
asynchronous operation for vary large queries.

Am I alone in this addiction to customer requirements and pragmatism? Am 
I just being very short-sighted? Everyone else in this list is sure we 
need the generality, complexity, and sophistication that TAP may provide 
eventually?
Roy


(*)
http://cas.sdss.org/dr7/en/tools/crossid/crossid.asp
http://irsa.ipac.caltech.edu/applications/Gator/GatorAid/upload.html





Ray Plante wrote:
> Hi Roy,
>
> On Fri, 6 Feb 2009, Roy Williams wrote:
>> and doesn't give our customers anything that they will value.
>
> I think this mischaracterizes the TAP effort.  We have seen from our 
> own summer schools that OpenSkyQuery is clearly near or at the top of 
> the list of things people find most valueable.  TAP is intended to be 
> a better OpenSkyNode.
>
> It is also intended to be a better cone search, able to do 
> multi-cones. More to the point, TAP is meant to be a general 
> foundation that many capabilities can be built upon.  This is 
> understandably harder to do than a simple cone search or a simple 
> multi-cone search.
>
> Now, it's understandable that you might not want to wait around for 
> TAP to settle to get a multi-cone capability.  And you can argue that 
> it's more productive to start simple, which is why we have cone 
> search.  But we've also demonstrated that, unless you are really lucky 
> or really smart, it's hard to go from simple to general without a 
> major rewrite.
>
> I might suggest that if you would like to see a simple multi-cone, 
> perhaps building on the current cone search, that you draw up a proposal.
>
> cheers,
> Ray
>

-- 

California Institute of Technology
626 395 3670