[fitsbits] programming interfaces for WCS defaults

[Frank Valdes]

> In article <mailman.1038369601.24251.fitsbits at listmgr.cv.nrao.edu>, Steve Allen <sla at ucolick.org> writes:
> From: Steve Allen <sla at ucolick.org>
> Subject: [fitsbits] programming interfaces for WCS defaults
> 
> With the FITS WCS papers I and II all but in print I will dare to raise
> questions of interpretation regarding alternate coordinate descriptions.
> 
> WCS paper I permits 27 different coordinate systems to be defined for
> a given situation.  The primary coordinate system has version
> character ' ' (space), and the 26 alternate coordinate systems have
> the version characters 'A' through 'Z'.
> 
> WCS paper I also defines default values for each of the WCS keywords
> which are to be used if some of the keywords are not present.
> 
> This effectively means that all 27 coordinate systems are always
> defined.  In the case of a PHDU or an IMAGE extension they default to
> an un-named identity WCS which gives world coordinates that match the
> Fortran-like FITS pixel array coordinates.
> 
> Note that it is not helpful to assert that at least one of the WCS
> keywords for a particular version must exist in order to instantiate
> that version.  The author of a FITS HDU may simply insert
> WCSNAMEA= 'My silly instance of the default world coordinate system'
> along with no other keywords for WCS version A, and by so doing the
> author has instantiated WCS version A with a WCS that is not really
> useful.

The problem with lawyerly nitpicking is its absence of common sense.  My
philosophy in FITS design is that the standards need to give the
flexibility to express information in a fairly natural way and satisfy
different approaches while expecting the author to use common sense and not
just obfuscate.  This is why I support the use of default values for
missing keywords.

So while it is true that by defining defaults for all keywords one could
make the claim that all 27 WCS objects are defined, I would choose to
interpret and built software that uses the common sense argument that
a WCS is defined only if at least one keyword is present.  I find nothing
wrong with the WCSNAMEA example above except that it is lawyerly nitpicking
which I can't imagine someone doing for real FITS interchange purposes.

In order to support older FITS data I would expect possible situations
with some WCS keywords but not CTYPE.  However for new WCS following the
ideas of the many people contributing to paper I and written down by
Eric and Mark, I would urge that a minimum prescription must include
CTYPE.  CTYPE is fundamental because this is what defines the "method"
for a WCS.

> 
> Here is the question in two variant forms:
> 
> How does the user interface of a FITS viewing application inform the
> user whether or not there is a *useful* definition for any particular
> version of WCS?

A viewing application, in my view, will scan the header and make a menu
of available WCS by the presence of at least one keywords.  The user
interacts with the application by selecting from this menu.

> 
> The same question can be generalized to the level of an application
> programming interface -- how does the FITS toolkit library inform the
> application programmer whether a WCS is defined, or whether it is only
> partly defined and some values have reverted to default?

A WCS toolkit need not provide the application with any information about
whether a WCS parameter is a default because of a missing card.  In a
WCS tool kit I think it would have an interface treating the WCS as an object.
If an application "really" needed to know this it could determine it by
other parts of the FITS toolkit that just deal with keywords.  So an
application, if it choses to build more knowledge about WCS than it should,
could simple use the keywords access layer directly to ask if CRPIX1 is
present in the header.  However, for doing things with a WCS layer it
would just discover if WCS 'A' is present and then evaluate it, update it,
etc. as an object.

The tricky thing in this WCS toolkit layer is what to do when the WCS is
updated.  Should parameters with missing keywords that still take their
default be included?  Should parameters, however they were set, that end up
with default values be given?

My first thought is that such a toolkit would have one or more options
to advise it how to output keywords from a WCS object to a FITS header
object.  The choices might be "write all keywords regardless of defaults",
"write only keywords which don't match the default values", or some
more complex thing where the application defines which keywords must
be written and which can be left out with default values.


A subthread between Steve and Dave is about having standards for WCSNAMEs.
It is clearly tempting to try and get the astronomy community to define
some standard WCSs.  I suspect this might be as difficult or more difficult
than the WCS issues dealt with so far.  I believe two things have to start
happening for this to develop.  One is that different groups would start
using WCSNAME for what they think are "standard" WCS in their situation.
For instance the IRAF "physical" system which maps raster-type operations
(subraster extractions, block averaging, pixel replication) back to the
original FITS pixel coordinates.  The other is someone brave or foolish
enough to write a draft convention for discussion.  Dave/Starlink is
proposing one interesting model.

Frank Valdes
NOAO