amsr at jb.man.ac.uk
Thu May 25 09:51:28 PDT 2006
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.
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
More information about the dm