Tim,
> Specifically, we feel that the ASTART, AEND, and AUNITS parameters in
> NDFTRACE output should reflect the astrometry of the currently selected
> frame rather than just the AXIS component. That change would remove the
> need for GETBOUND.
>
> Not sure how much of an impact this would have for support of backwards
> compatibility of scripts. I suppose it depends on how many people are
> using ASTART and AEND to get axis bounds. [in which case we would need 3
> new parameters for WCSSTART, WCSEND and WCSUNITS]
Not keen on subverting ASTART, AEND and AUNITS. Partly because of the
backward compatibility issue, but also because it blurs the distinction
in meaning and use between AXIS components and WCS components.
Do not forget that WCS coords are not restricted to being separable
into independant axes, unlike AXIS structures. So for instance, you need
to think about what happens if you use ndftrace on a 2D image of a small
area at the north celestial pole.
Are you objections to using new parameters simply the proliferation of
extra parameters?
In fact you can use astmapbox in ATOOLS to get the bounds of a given WCS
axis over a given region of grid coords. So to get your desired effect you
would need to run NDFTRACE to get the dimensions of the image in pixels,
then use ASTMAPBOX to get the corresponding limits on a specified WCS
axis. In tcsh, it could be done as follows:
ndftrace $1 quiet
set a = `parget dims ndftrace`
astmapbox $1 "[1,1,1]" "[$a[1],$a[2],$a[3]]" forward=y coordout=3
The upper and lower bounds of WCS axis 3 would then be stored in output
parameters LBNDOUT and UBNDOUT of ASTMAPBOX.
In fact, just hang on a mo...
OK, I've just changed astmapbox so that the LBNDIN and UBNDIN parameters
default to the grid bounds of the input NDF. So now you can just do
astmapbox $1 \! \! forward=y coordout=3
I.e. no need to call ndftrace first.
Does this meet your needs?
David
|