[QUANTITY] How to store coords, why iteration order is ok in locator (Was: Re: [QUANTITY] Data Model for Quantity v0.5

[Brian Thomas]

On Wednesday 12 May 2004 12:15 pm, David Berry wrote:
> Brian,
>
> > But for n-dimensional data cubes in general, say something that
> > holds info on R, T, D (Radius, Temp, Density) you have 3 orthogonal
> > axes, and  perhaps you wish, for purposes convenient to your
> > application/code with a different ordering.. say (to use your example)
> >
> > (1,1), (2,1), (3,1), ...(3,3)
> >
> > instead of the stored order of
> >
> > (1,1), (1,2), (1,3), ... (2,1), (2,2), (2,3), ...
>
> OK. I can see that people may want to step through the N-d array using
> some other axis order that the usual one for their language. But this only
> relates to actual array indices - how can it relate to any other
> generalised non-linear world coordinate system? IN your example you say
> the 3 axes are orthogonal, but what if they are not orthogonal? What if
> there is some complex non-linear dependancy betwen them?

	But I *already* covered this in my prior email. IN the case that
	the you have "not orthogonal" coordinates, you have to build
	a single axis which is a vector. We already agree that this is the
	correct way to handle sky coordinates Ra,De. And as I stated
	in my prior email, since you have only one axis in the skyVector
	case, you *can't change the iteration order* (because there is only
	one axis!!!!).

>
> If locators are only of use in the very specific case of WCS Frames
> containing axes which are orthogonal to each other

	Which happens all the time I might add. Not all data are organized
	by sky (or pixel) coordinates which have dependent components(!!!!!).
	There are many, many examples of people creating tables of various
	properties which are orthogonal to each other in property space.

>  and in which there is
> an exact one-to-one connection between WCS axes and pixel axes  (i.e. each
> WCS axis depends only on one pixel axis), then locators should not be
> included as part of the model because we are aiming at a *general* model
> and we should not be forced to shoe-horn the general case intothe mould of
> one very specific individual case.

	As I have said (exhaustively) now, this isn't a problem. Pixel/sky coords
	must be stored as a vector, which is a single axis. It is impossible in the
	model, as it currently stands, to change the iteration order on this type
	of data because there is only one axis.

> [snipped remainder of repeating argument..]
>
> My proposal is to to allow the selection of a "current" WCS Frame (as is
> already allowed in the interface), and then for application code to
> specify explicitly the coordinates (within the current Frame) in which it
> is interested. What does this scheme miss? Why do we need locators?

	We need locators because it allows for more sophisticated access than
	i, j, k indices. The locator encompasses i,j,k access, so I'm not sure what
	your issue is with allowing more functionality than that, but I'm too tired 
	repeating myself to go further than that at this moment..

	-=b.t.

-- 

  * Dr. Brian Thomas 

  * Dept of Astronomy/University of Maryland-College Park 
  * Code 630.1/Goddard Space Flight Center-NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128 [GSFC]
           (301) 405-2312 [UMD]