On Mon, 17 Jul 2006, Tim Jenness wrote:

> On Fri, 14 Jul 2006, Mark Taylor wrote:
> 
> > On Thu, 13 Jul 2006, Tim Jenness wrote:
> >
> >> This all sounds great.
> >>
> >>>       - Make a PLASTIC request to all capable registered applications
> >>>         asking them to display a FITS image:
> >>>
> >>
> >> Is it allowed to have an NDF display message as well? (if I switch ORAC-DR
> >> to PLASTIC I'll need to do that)
> >
> > No reason why it can't have NDF-specific messages, however I wouldn't
> > necessarily encourage you to switch to PLASTIC from whatever ORAC-DR
> > is using now for communication with GAIA.  Doing that might possibly
> > make sense, but then again it might not - I can discuss this further
> > if you want.  (Not that I imagine you were talking about doing it in
> > the immediate future in any case).
> 
> No I wasn't, but clearly being able to send NDF instead of just FITS would 
> be useful for is. I was just trying to make sure that FITS is not the only 
> image transfer scheme that PLASTIC is allowed to use.

The protocol is explicitly designed for extensibility, i.e. there
is nothing to stop anyone adding their own messages with whatever
semantics they want.  Currently the developer community is small
enough however that by informal consent all messages are being
discussed on the developers' mailing list prior to introduction.

So far, by the above-mentioned informal consent, images are being 
transferred using FITS and tables using VOTable.  There is an 
advantage to sticking to these formats, namely that if you are 
writing a generic client application you only need to think about 
a single message ID for transmitting/receiving each type of data, 
rather than having to support a long (well, plural) list of 
messages one for each format of each data type.  Whether that 
practice will persist for generic messages, or whether formats
will become more fragmented, is an issue which will probably 
only get resolved by waiting to see how usage develops.  
Either way, for a closed group of applications such as 
(ex-)Starlink ones I don't see any problem in practice
or theory for adding a new set of NDF-based messages, though
(no surprise) you wouldn't necessarily expect non-Starlink 
generic applications to support such messages.


> >>>       - Select menu item Interop|Send FITS Image to...|Send to gaia
> >>>         from TOPCAT's density window.  It should appear in GAIA.
> >>
> >> TOPCAT should be able to send polarimetry information to GAIA as well
> >> (once the pol widget is plastic accessible).
> >
> > I know 0 about polarimetry.  What does pol data look like
> > (i.e. is it a table or an N-dimensional array or something else)?
> 
> Table. See attached output from polpack.
> 
> I think it has an AST header for astrometry (which you will need to 
> ignore) but it's really just columns of
> 
>    X  Y I Q U P theta PI
> 
> with errors for each column.

OK well there is an existing message:

   boolean ivo://votech.org/votable/loadFromURL(String url, String id)

which just has the semantics "do something with this table if you want".
This would work, but runs the risk of SPLAT picking up or attempting
to pick up a table which is nothing to do with polarimetry 
(typically, an object catalogue), depending on how indiscriminately 
the user/application sending the table broadcasts it.
I wonder if that's a problem.  Most of the tables we've been
playing with in PLASTIC so far have in fact been object catalogues
so this sort of thing hasn't arisen.  Hmm.

> TOPCAT should really be allowed to send a catalogue to GAIA for overlay as 
> well although that might require that GAIA be able to respond to a 
> question along the lines of "what area of sky are you currently 
> displaying".

Certainly - communicating object lists between image- and table-analysis
applications is basically the first and canonical use case for PLASTIC.
Currently the votable/loadFromURL message mentioned above is the
one used for this.  Once we've worked out how to handle VOTables in
GAIA this should be a piece of cake.  Ditto sending tables back 
again (though perhaps not quite so useful).

A related thing is communicating object selections (in TOPCAT language:
row subsets) between GAIA and TOPCAT.  This is where two (or N) 
applications are looking at the same catalogue, and one says 
"focus on this subset of the rows".  From TOPCAT to GAIA it means 
that you can focus on a particuar sub-population, for instance the 
result of a match or a magnitude cut etc.  From GAIA to TOPCAT you 
could mark out a set of objects in a particular sky region or 
with certain visual characteristics.  If we had that between GAIA
and TOPCAT, then GAIA would be about as PLASTICised as Aladin,
which is currently the most (actually, only) PLASTIC-friendly image 
viewer, so it would be very nice to get done.  Peter: is specifying 
selections from catalogues something that happens in GAIA at 
present or not?

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/