On Tue, 11 Dec 2007, Tim Jenness wrote:
> The SCUBA-2 FTS team are using java to do their data processing. They
> are using starjava in some places (since they are reading and writing
> NDFs) but there are a couple of things that they want to be able to do
> but don't know how (and I have no idea):
Tim, this whole idea throws me a bit. When you say they are reading and
writing NDFs and are using STARJAVA, are you saying they are already
accessing NDFs using STARJAVA? In which case how?
As Mark points out (sorry my memory of this whole area is getting quite
vague now) outside of SPLAT, NDF access is done using JNIHDS. We did some
work in adapting this to the NDX concept (which exists as an API based
losely on the NDF data model, but with support for various possible data
formats), but that wasn't really completed, so there's no support for none
trivial extensions. So:
> - Is extension propogation easy?
>
> - Is there code for reading a .MORE.FITS extension, modifying it and then
> writing it out again. Do they need to use their own code for reading
> and writing and a FitsChan for all the manipulation (ie a java clone
> of kpgGtfts and kpgPtfts)?
>
> - They have a requirement for writing out NDFs into an extension of an
> NDF. Is that easy?
no to the above (but remember we also have JNIAST, so the FitsChan
handling isn't that arduous).
> - They need to write an AXIS component in the primary NDF (in principal
> they could do this as a specFrame since the AXIS contains the
> wavenumber of each spectral channel). Would it be easier to do this in
> AST land or is there an easy way in Java to write the .AXIS.
Letting the NDF library update the AXIS component from the AST WCS, would
be the best way, but since NDX doesn't support axes (we considered these
deprecated in the AST era), that's not much help.
> - Writing the new provenance information would be useful but I'm
> assuming that would need new code for writing a compatible
> entry to the structure (they aren't using NDG) or a standalone
> routine to allow the provenance to be updated afterwards.
Indeed they would.
> I have a feeling that access to the NDF library is only available
> through splat. I'm having visions of them writing SIMPLE NDFs
> manually using HDS.
That's right. SPLAT is the only package that actually uses the NDF
library, but the JNI interface is just what SPLAT requires, and works at
quite a high level (and does do some of the above I must admit), I've made
no attempt to support the whole NDF library (in fact if the NDX work ever
completed this whole part of SPLAT would have been abandoned and all the
JNI libraries in STARJAVA would have been pure C, we always wanted to move
to a pure Java solution).
So, the upshot is that I suspect they'll have to use JNIHDS to do this
work (or extend the SPLAT work). Notice that Mark did some similar-ish
efforts (accessing NDFs using JNIHDS) in Treeview to display the contents
of NDFs. These are in the datanode package.
Peter.
|