On Wed, 16 Feb 2005, David Berry wrote:
> Can people let me know if they come across data files containing units
> strings which do not conform to the FITS standard. Pedro has a point in
> saying that requiring FITS conformity is a bit of an imposition on data
> providers. I can see that there will be many common variants which AST
> could easily interpret, rather than reporting an error. Obviously,
> "angstrom" could be treated like "Angstrom, "hz" like "Hz", "micron"
> like "um", etc. "A" could probably be treated like "Angstrom" since it is
> unlikely that an astronomcal data file will refer to units of Amperes!
> Unfortunately, "a" is a common (in fact IAU) unit for year.
>
> So maybe I should add some flexibility to the AST unit interpretation to
> cover these cases.
David,
see:
java/source/splat/src/main/uk/ac/starlink/splat/util/UnitUtilities.java
this is my current list of unit string fixups for SPLAT. Clearly I have an
area of interest so I can assume a = Angstrom, so not all of these are
likely to be of use.
One further point (was tempted to respond to Pedro with this, but I don't
want him to think we're ganging up). This business is a little spurious as
an SSAP reponse will (or that maybe could, the specification is a bit
vague on this) include the units strings anyway -- in fact all the ones
I've seen do, see the attachment for an example response. So it should be
no more bother to fix those up from the VO perspective as derive the
dimension expressions. Naturally fixing the actual data files is more
difficult, but dimensional analysis doesn't do that either. This latter
point is vital for SPLAT, I open a lot of existing data files.
Of course this whole area is a bit of a mine field, do I take meta data
from the response or the data. I choose response over data meta data, but
for the spectral coordinates that typically not much use as I just see the
string "Angstrom" or whatever, lacks a bit of detail.
Cheers,
Peter.
|