On 22/05/07, Tim Jenness <[log in to unmask]> wrote:
> On Tue, 22 May 2007, David Berry wrote:
>
> >> In my opinion though the "*" at the front looks really superfluous. I'd
> >> suggest that we forget about AXIS completely. If something has a decimal
> >> point in it or hms/dms, treat it as a WCS section. If there is no WCS use
> >> AXIS as now. I don't really see any reason to stick with the "section
> >> refers to AXIS" notion since most people using AXIS don't have .WCS and
> >> most people using .WCS don't even know what AXIS is.
> >>
> >> If we do that the "*" disappears. The "*" isn't needed either way in the
> >> above since surely the parser will be clever enough to spot a hms? (even
> >> if it needs two passes through the string).
> >
> > The problem is how to distinguish the order in which axes are
> > specified; should NDF assume that the bounds are supplied in pixel
> > axis order or in WCS axis order? There's nothing to say that, for
> > instance, WCS axis 3 and pixel axis 3 are associated with each other.
> > The point is, you can permute the WCS axes into any order you like
> > without permuting the pixel axes. So how does the section parser know
> > which order to use?
>
> Groan. I'm just having flash forwards of moaning astronomers who will
> always be using either PIXEL or WCS sections and the subtlety of AXIS
> sections will completely pass them by.
It's nothing to do with AXIS structures - they are simple because they
always have a one-to-one correspondence with pixel axes - that is,
'AXIS' axis N is always associated with pixel axis N. But that's not
the case with WCS axes. Say you have a spectral cube called fred.sdf
with WCS axes (galactic longitude,galactic latitude,velocity) which
map on to pixel axes (2,3,1) respectively, and the user specifies the
section
fred( 12.2:12.4, 83.2:84.1, 101.0:102.0 )
how does the NDF library decide what each of these 3 bounds values
refers to? Do you interpret them in pixel axis order (which would come
out as galactic latitude, velocity, galactic longitude) or in WCS axis
order (which is galactic longitude,galactic latitude,velocity).
Previously, bounds were always supplied in pixel axis order, so I'm
suggesting the "(*" syntax as a means of flagging that the values are
supplied in WCS axis order. A possible alternative means of doing this
flagging would be to say "If all bounds are supplied in non-integer
format, then assume WCS axis order, otherwise assume pixel axis
order". Reduces the amount of syntax to remember, but increases the
amount of "special case behaviour" to remember.
An additional problem is that, if WCS bounds are supplied, then you
need to supply a complete set of WCS bounds for all pairs of celestial
longitude/latitude axes. That is, you can't mix WCS bounds with pixel
index bounds for celestial axes because you cannot transform longitude
or latitude values independently of the other.
> Looking forward to that CHANMAP example...
Whilst it will probably do something sensible with a CHANMAP I'm not
sure it would ever be of any use.
David
|