Comments on Image Data Model

[Douglas Tody]

On Mon, 5 Nov 2012, Markus Demleitner wrote:
> I think you are right -- we should not (now) express the WCS
> transformation using STC, whether or not it is expressive or not to
> do that; at least we should not require the representation.  WCS is
> fine for what it does, and there's broad tool support for it.  So, we
> should probably just leave it like it is -- as an opaque CLOB to be
> interpreted by user software.

This could be the simplest way if we were merely passing the WCS through
as a blob to be interpreted by WCS-oriented software, e.g., to compute
coordinates from an image returned to the client (but we can already do
that as the WCS is included in the output image dataset).

The problem is that for advanced image access using AccessData we need
to compute using the WCS information combined with other information
from the filter and/or image section terms.  This happens both on the
client side where we compose the parameters to define the operation, and
on the server side where we need to combine all these terms to define
the overall transformation of the input dataset.

To compute using a WCS serialized as a bunch of FITS keywords the first
thing we will need to do in our code is reconstruct the WCS parameters
from the FITS encoding.  This means applying the FITS WCS encoding rules
and composing the reference pixel array, CD or PC matrix, etc., from
multiple "ijk"-suffixed keywords.  What we end up with are the elements
of the WCS data model in scalar and vector valued variables in our code,
after which we can easily perform the computation.

Buf this "parsed" WCS is exactly what the Utype decomposition provides
us.  This provides the elements of the WCS in a simple name/value form
supporting array values, suitable for computation in any language,
without having to be concerned with the details of the awkward FITS
serialization.  The Mapping model is semantically equivalent to FITS
WCS, but makes the content of the WCS model available in a convenient
form consistent with all the other parameters of the interface, so that
we can more easily manipulate it using the standard facilities already
provided for manipulating a VOTable or Utype encoded data model.

So yes, if we were merely passing the encoded WCS around as a blob
passed on to external code then keeping it as a blob would probably be
simplest.  Since we actually need to manipulate the content on both the
client and server end however (as well as store it in forms such as an
archive DBMS table), it would actually be more work to have to deal with
the FITS encoding.  The client would need extra code to compose the
blob, and the service would need to decode it before being able to use
the content.

An additional issue is that, while FITS WCS deals fairly well with the
issue of defining the spatial and spectral axes of an image, it is more
limited for the time and polarization axes.  Mapping allows us to
provide something which is semantically equivalent to FITS WCS but in a
convenient form consistent with our other VO metadata, which we can
extend as necessary to deal with aspects such as time and polarization.
This is done by incorporating elements of STC (without having to deal
with the complexity of the full model or yet another serialization), or
in the case of time, the draft FITS WCS time model, which is also from
Arnold and already consistent with the FITS WCS model.

 	- Doug



> Hi François,
>
> On Mon, Nov 05, 2012 at 05:51:03PM +0100, François Bonnarel wrote:
>>     That's the reason why I thought the direct mapping of WCS
>> Keywords into utypes as proposed by the SIA2 2009 draft with a more
>> straightfoward solution.
>
> I think you are right -- we should not (now) express the WCS
> transformation using STC, whether or not it is expressive or not to
> do that; at least we should not require the representation.  WCS is
> fine for what it does, and there's broad tool support for it.  So, we
> should probably just leave it like it is -- as an opaque CLOB to be
> interpreted by user software.
>
> Yes, we're tieing us to WCS in this way, but I guess that's a
> reasonable price to pay; trying to disguise that fact by mapping FITS
> card keywords to something that looks like utypes does not seem
> helpful to me.
>
> Whatever we want to represent that's not (or not directly) in WCS, or
> what's straightforwardly done in STC -- sure, let's do it the IVOA
> STC way.  But let's not redo WCS if we don't have a very strong
> agenda for that.
>
> Cheers,
>
>          Markus
>
>