[TRANSFORM] What is a "frame"?

[David Berry]

Ed,On Thu, 6 Nov 2003, Ed Shaya wrote:

> What you describe here sound like what is called pseudocode and it
> is a good idea for us to work out such a system.  We could use your
> VOMapping.  Perhaps though we should look into WWW standards on this.
> It could be that one can MathML or if UML ever gets to the point that
> one can autogenerate all the code that we need, we could use that.
> Something called xUML claims to do this.

MathML could indeed be an alternative route to follow. I do not know much
about it. Anticipating one of your later comments, is it restricted to
mappings between numerical values, or can it be used to describe more
generalised mappings between objects of any class?

> But, back to your question on URL. I think it is not dangerous to use a
> URL to get code.  Our systems can be designed to download software the
> first time it is pointed to and then know that it is cached locally
> everytime it sees the same URL.  In the metadata working group we have
> discussed XML Catalogs which would do this and also perhaps keep track
> of mirror sites for any IP address.

Yes, this would be a useful facility, but I think it would take a lot of
time and effort to make it work effectively. One problem could be that it
puts restrictions on the language in which the client is written - to use
this facility clients would need to be written in a language which can
run the code received from the URL - not everyone uses Java for instance.
An alternative approach could avoid the need to download any code by
making the URL identify a web service which would perform the mapping for
you, but that would probably be far too slow for most situations where you
would want to use a Mapping.

Also there would need to be a standard way for a downloaded Mapping to
specify what parameters it needed to define its algorithm.

I think we could get 99% of the likely requirements for Mappings
by an extensive list of built-in Mappings. We could then extend the
Mapping class to produce a "URLMapping" class at a later time when it
prooved to be necessary. That is, the base (abstract) Mapping class should
not care whether its definition is built-in to the client code, or is
downloaded from a URL.

> >
> >3) You have components marked "Input". Some of these seem to be values
> >which parameterise the algorithm (e.g. centerRADE, pixelsPerArcsec, etc),
> >but others (Frame1) seem to define the actual input coordinate system used
> >by the Mapping [By the way, OutputUnits should be contained within "frame1"
> >since it forms part of the description of the output coordinate system].
> >These are two very different sorts of "input". I'm happy to see the first
> >type (algorithmic parameter values) inside the Mapping, but not the
> >second (descriptions of coordinate systems).
> >
> Frame1 is the output coordinate system info that the code needs to know
> to choose which branch of code to go down.

Yes, this info needs to be available somewhere, but it should not be *part
of* the Mapping. If you have the Frame inside the Mapping, then you get
into problems when you combine Mappings together because you need to check
that the output coordinate system produced by the first Mapping is the
same as the input coordinate system required by the second Mapping, etc.
So you need Mapping variants for a potentially very large number of
different and unpredicatable coordinate systems.

> Mapping of frames is not the most general type of mapping and I am
> trying to put it into the framework of any Mapping.  Does it map between
> 3 Johnson UVB images to a Cousins I image? Does it map between astronomical
> terms and space physics terms?

Good point. I agree that I have been focussing so far on Mappings which
transform an input vector of floating point numbers, into an output vector
of floating point numbers. But the same argument applies even if the
extend the definition of a Mapping to allow it to transform an arbitrary
input object into a corresponding output object. To allow this
(potentially very useful) generalisation, all that is needed is that the
Mapping contains a description of its input and output *data types*. By
data type I mean simply the data type, not the "coordinate system"; for a
given data type could, in general, be used to describe positions in many
different "coordinate systems". So I am happy to extend the abstract base
Mapping class to be something like:

Mapping {
  DataType InputDataType;
  DataType OutputDataType;
  Boolean ForwardTransformationDefined;
  Boolean InverseTransformationDefined;
}

Where a DataType defines the type of object which the Mapping can
transform, in terms of its shape (scaler,vector,etc) and the data type
(float, int, string, boolean, etc, or any other class of object).
So, whilst I agree that a general Mapping should include meta-data to
specify its input and output data types, I still think that the Mapping
should not include any meta data which says what the input and output
objects are being used to represent (i.e. the Mapping should not
include the input and output Frames), because if you do, you put
restrictions on how the Mappings can be joined together. The only
restriction should be that the OutputDataType of the first Mapping
matches the InputDataType of the second Mapping.

One *may* be tempted to define a DataType of (say) RADecPosition
which encapsulates a pair of floating point numbers, together with an
Equinox, epoch, etc.  In effect, this is a DataType which includes a
Frame. But this would be "bad practice" in most cases, because it imposes
unnecessary restrictions on the use of Mappings. Let's say we define a
sub-class of Mapping called NegateMapping which takes a vector of floating
point number (of any length) and simply negates all the values. Its
InputDataType and OutputDataType may be specified as something
like "float[]". In principle, there is no reason why you should not be
able to use this Mapping on a pair of floating point numbers representing
an (Ra,Dec) position, but if (RA,Dec) pairs were represented by a special
RADecPosition data type, then you wouldn't be able to.



David

----------------------------------------------------------------------
Dr David S. Berry    (dsb at ast.man.ac.uk)

STARLINK project                        Centre for Astrophysics
(http://www.starlink.ac.uk/)            University of Central Lancashire
Rutherford Appleton Laboratory          PRESTON
DIDCOT                                  United Kingdom
United Kingdom                          PR1 2HE
OX11 0QX