 |
 |
On Tue, 18 Jul 2006, Tim Jenness wrote: > > 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 > > GAIA. > > > 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. > > Ok. So you can send it to GAIA but GAIA won't know to use the polarimetry > display widget without scanning the columns and thinking that those P and > ANG columns plausibly look like pol data. > > Two things: > > 1. I'm thinking that polpack should add ra/dec columns at the end > to enable non-starlink applications to be able to place the > vectors at the correct place on an image. (GAIA, CURSA, POLPACK > and KAPPA look at the frameset). These can be ignored by clever > applications. That certainly sounds like a good idea. > 2. Is there any information we can add to the header of the FITS > table to enable an application to know that there are pol > data in it? (UCD???) [or is the concept of polarimetry so foreign > at the moment that no-one has even considered non-mag columns for > display in any means other than a cross at the correct place) To backtrack a bit: rather than using non-standard TUCDnn FITS headers, a better solution (which is also current practice) would be to transport the tabular data in a VOTable which has better metadata facilities. Whether that is feasible for GAIA is still to be determined depending on how we sort out GAIA's VOTable facilities. To indicate that the table itself is polarimetry data, it is probably better to label the table itself (utype or ucd attributes of the TABLE element, or some use of PARAM elements) rather than grubbing through the columns to make a guess about this. An alternative would be to introduce a new message with the semantics "here is a table containing polarimetry data - do something with it if you want". I don't understand the polarimetry interoperability use cases well enough to know whether that's a good idea 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/