[fitsbits] start of Public Comment Period on the Green Bank convention

Mark Calabretta mark at calabretta.id.au
Tue Jun 23 01:06:12 EDT 2015


On Mon, 22 Jun 2015 11:29:49 -0400
Bob Garwood <bgarwood at nrao.edu> wrote:

Hi Bob,

> In order to further save space, it was decided that for column values 
> that don't change from row to row in the table that you could represent 
> those columns as keywords.  They called these virtual columns.  There's 
> no indication in the FITS file that this convention is in use.  (the 
> single dish FITS convention makes use of the Green Bank convention, but 
> that has a separate signature via the EXTNAME value).

The WCS standard defines keywords like jCRPXn, that apply to all rows
of a binary table.  The Green Bank convention simply says that where the
value changes from row to row, jCRPXn can be expanded into a column with
TTYPEn = 'jCRPXn'.  So the direction for WCS keywords is from keyvalue
to column.

For non-WCS keywords, it is as you said -- the Green Bank convention
allows a column containing a constant value to be collapsed into a single
keyvalue, provided that the column name (TTYPEn) can become a legitimate
FITS keyword.
 
> I'm not sure I see the need to add this to the standard as it's more a 
> question as to how a consumer of this table uses that information.  A 
> general reader should just present things as keywords and columns as 
> written.  As a consumer, I've written code that presents things opaquely 
> to downstream code so that when the downstream code asks for a value it 
> doesn't need to know whether that value is stored as a full column or as 
> a keyword - it expands the keyword to a constant valued vector as 
> necessary to satisfy the request, for example.  But I don't think I want 
> the general purpose underlying reader to do that for me.

I don't understand why you say this.  The Green Bank convention requires
special-purpose code to be written that understands it, e.g. the library
code that you wrote to support the application code.  That library code
must be based on a specification, and that specification ought to be
standardised.  If it's standardised, as I believe it should be, then
I'll support it in WCSLIB.

Regards,
Mark Calabretta



More information about the fitsbits mailing list