STC ObservationLocation

[Anita Richards]

I agree with Jonathan - we have to rely on people for whose data it is 
important filling it in, otherwise don't make publishing data full of what 
will be perceived as irrelevant burdens.

cheers
a

PS - example - combined images made from two interferometry arrays, one 
uses array-centred and/or left-hand coordinates, the other geocentric 
and/or right-handed.  I am sure that there is a way to cope in STC but for 
most images it is almost never an issue and for visibility data the 
specialised software had better be able to interpret the positions which 
should be attatched to the data....  either way, many data publishers are 
not going to know nor care.  80:20.

> Sorry Arnold, but I would also vote for the ObsLoc to
> be optional for coordinate systems which have already
> been corrected for observatory location. In the language
> of the Observation DM, the ObsLoc in those cases has become
> Provenance (check it if you don't trust the data) rather than
> Characterization (what you still need for further work if you
> do trust the data). One could have another STC instance for
> the original as-observed coordinate system in the Provenance
> (optionally!) but the main and required STC would not need
> ObsLoc if everything is barycenter corrected.
>
> Roy and others, note however that some data has some
> things corrected (e.g. velocity frame) and not others
> (apparent position? time?) and so you have to be a little
> bit careful about throwing away ObsLoc. But if the
> accuracy of the data is such that remaining corrections
> are small compared to the quoted errors, then I think there's
> no problem (e.g. if your time accuracy is 10 minutes, who
> cares if we are in TT or TDB with a 2 ms max difference...).
> This is the sort of thing that should go in a usage guide.
>
> - Jonathan
>