Next draft of VOTable in STC

[Rob Seaman]

A few questions:

Is the intent that STC-in-VOTable be able to represent the full richness of STC?

I suspect that others marvel as I do at the unending special cases that continue to appear in space and time coordinate use cases.  That being said, what is the range of these that must be supported in a "broad-spectrum" application/format (eg, VOTable), or a narrow-spectrum application/format (eg, VOEvent)?

IVOA data models have large numbers of degrees of freedom.  IVOA applications often require many fewer such, especially to reach the canonical "90%" level of applicability.  How best should this be managed?

How do non-IVOA projects handle FK5?  Do they average the two epochs?  Correct for proper motion separately in each coordinate?  Etc and so forth.  What fraction of community software applications of various types (observing preparation, pipeline processing, etc) actually handle FK5 "correctly"?  What are the implications if such applications don't?  How many (and how important) are the catalogs that require such dual epochs?

Rob
--

On Jun 11, 2010, at 11:11 AM, Steve Allen wrote:

> On Tue 2010-06-08T17:19:29 +0200, Markus Demleitner hath writ:
>> I've put up another draft of the STC-in-VOTable note at
>> http://vo.ari.uni-heidelberg.de/docs/note_stc_20100601.pdf.
> 
> Perhaps this possibility has already been dismissed, but I note that
> the model only provides a notion of epoch for an ensemble of
> coordinates, not for the individual coordinate components.
> 
> This means that the model cannot communicate, e.g., the FK5 catalog in
> which the technologies by which they were measured result in one epoch
> for RA and a separate epoch for Dec.
> 
> Representing the FK5 catalog would presumably require utypes akin to
> stc:AstroCoords.Position2D.Epoch2.C1
> stc:AstroCoords.Position2D.Epoch2.C2