 |
 |
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. Keep the "(*" then but it's critical that you add the "if AXIS is requested but no AXIS exists, assume WCS before assuming PIXEL" option. That will appease all the ACSIS users since at least they will be able to section velocity scales without having the "(*" syntax. (and we will only have Figaro users to worry about...) > 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. Looking forward to that CHANMAP example... -- Tim Jenness JAC software http://www.jach.hawaii.edu/~timj