[fitsbits] start of Public Comment Period on the INHERIT convention

[Arnold Rots]

We pretty much go a similar route:
The primary header contains an essential summary with keywords
that are common to the following extensions, but these are all
repeated in the subsequent HDU headers so that each HDU is
self-contained.
In terms of software architecture, this means that a tool can be
handed an HDU that contains all the information it needs; the tool
won't have to inherit anything or know anything else about the file.

Cheers,

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------


On Thu, Jul 2, 2015 at 1:16 PM, Phil Hodge <hodge at stsci.edu> wrote:

> Your lower-level software knows where to go (e.g. extension 10 in an MEF)
> to find the data.  It could also know where to get the keywords.
>
> Lately I've been using astropy.io.fits, or an interface that uses
> io.fits.  The C interface that we used for calstis has a layer based on
> CFITSIO.  So yes, I do use a library :-) .
>
> Phil
>
>
> On 07/02/2015 01:00 PM, Frank Valdes wrote:
>
>> This is a programming practices question.  In our case we want
>> applications to be independent of the data format structure (possibly not
>> even FITS).  An application asks for the value of EXPTIME in an image (a
>> higher level construct which might happen to map to extension 10 in an
>> MEF).  The lower level image I/O software (layered on even lower level FITS
>> I/O in this discussion) handles this.  What you are saying is that high
>> level application software needs to deal with the format itself.  I would
>> pose the question, why doesn't your application open a FITS file as a
>> binary file and do all the parsing of the file rather than rely on a FITS
>> I/O layer such as CFITSIO, etc.  That would certainly be explict right? :)
>> [I really assume  and hope that you use some FITS library to get a keyword
>> and not direct file access to get your keywords.]
>>
>> But if you are saying why doesn't the lower level FITS I/O layer just
>> check both then basically this becomes the INHERIT implementation, right?
>>
>> Frank
>>
>>
>> On Jul 2, 2015, at 9:43 AM, Phil Hodge wrote:
>>
>>  What I don't understand is why you need to "inherit" these keywords.
>>> For DECam you have a convention that some keywords are in the primary
>>> header and some are in an extension header.  Why not just read or update
>>> keywords in the headers that actually contain the keywords? That's what we
>>> at STScI do for HST data, in spite of the INHERIT keyword.  Explicit is
>>> good.
>>>
>>> Phil
>>>
>>> On 07/02/2015 12:08 PM, Frank Valdes wrote:
>>>
>>>> I will respond with the DECam raw data from the telescope.  This is a
>>>> good question for this discussion.  If this goes somewhere interesting I
>>>> can look at the other NOAO mosaic cameras and the calibrated files.
>>>>
>>>> The keywords from the list at
>>>> http://heasarc.gsfc.nasa.gov/docs/fcg/standard_dict.html that are
>>>> inherited are:
>>>>
>>>> DATE-OBS, INSTRUME, OBJECT, OBSERVER, TELESCOP
>>>>
>>>> I might also mention a couple that are important but not on the list:
>>>>
>>>> EXPTIME, FILTER, RA, DEC
>>>>
>>>> There are no WCS keywords even from the advanced WCS papers or the TPV
>>>> convention used by DECam.
>>>>
>>>> Frank
>>>>
>>>>
>>>> On Jul 2, 2015, at 7:26 AM, Mark Calabretta wrote:
>>>>
>>>>  On Wed, 1 Jul 2015 11:30:12 -0700
>>>>> Frank Valdes <valdes at noao.edu> wrote:
>>>>>
>>>>>  DECam is
>>>>>> generating a huge amount of data (arguably the biggest optical data
>>>>>> source in the world) on an almost daily basis.  The raw data is an
>>>>>> MEF and uses INHERIT.  The calibrated data produces MEF with INHERIT.
>>>>>> All mosaic data that NOAO has in its archive, -- >10 yrs of Mosaic, >
>>>>>> 5
>>>>>> yrs of NEWFIRM, DECAM -- is in this format.
>>>>>>
>>>>> Which keywords known to the FITS standards are these files inheriting?
>>>>>
>>>>>
>>>>> Mark Calabretta
>>>>>
>>>> _______________________________________________
>>>> fitsbits mailing list
>>>> fitsbits at listmgr.nrao.edu
>>>> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>>>>
>>> _______________________________________________
>>> fitsbits mailing list
>>> fitsbits at listmgr.nrao.edu
>>> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>>>
>>
>> _______________________________________________
>> fitsbits mailing list
>> fitsbits at listmgr.nrao.edu
>> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>>
>
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.nrao.edu
> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/fitsbits/attachments/20150702/3c2d3e7d/attachment-0001.html>