On 22/05/07, Tim Jenness <[log in to unmask]> wrote:
> On Tue, 22 May 2007, Peter W. Draper wrote:
>
> > On Tue, 22 May 2007, Peter W. Draper wrote:
> >
> >> OK, quotes can be difficult to keep hold of, so how about:
> >>
> >> (*12h34m56s~1m19s:12h34m56s:12d35m01s)
> >>
> >> That's explicit and nothing special to anyone except the reader. Might
> >> mean a bit of extra work if the d/h don't match the axis.
> >
> > Sorry, for the confused that should be:
> >
> > (*12h34m56s~1m19s,12d34m56s:12d35m01s)
> >
> > to make sense.
> >
>
> I like this a lot. It especially makes it clear what units the string
> after the ~ is using.
>
> 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?
The current system just assumes that the bounds are supplied in the
order of the pixel axes. The point of the "(*" syntax was to indicate
that the bounds are supplied in WCS axis order. Also, it is possible
for there to be a different number of pixel and WCS axes.
David
|