2009/9/9 David Berry <[log in to unmask]>:
> 2009/9/9 Tim Jenness <[log in to unmask]>:
>>
>>
>> On Tue, Sep 8, 2009 at 9:49 PM, David Berry <[log in to unmask]> wrote:
>>>
>>> 2009/9/9 Tim Jenness <[log in to unmask]>:
>>> >
>>> >
>>> > On Tue, Sep 8, 2009 at 9:06 PM, David Berry <[log in to unmask]>
>>> > wrote:
>>> >>
>>> >> 2009/9/8 tim.jenness <[log in to unmask]>:
>>> >> > Provenance tracking can be enabled automatically using an environment
>>> >> > variable (AUTOPROV). No reason why HISTORY propagation can't have a
>>> >> > AUTOHIST
>>> >> > environment variable.
>>> >> >
>>> >> > For CONVERT I would be in favour of simply enabling HISTORY when the
>>> >> > file is
>>> >> > imported to NDF.
>>> >>
>>> >> OK. I'll add this issue to my do list. Not sure when it will make its
>>> >> way to the top though.
>>> >>
>>> >
>>> > Presumably tweaking CONVERT is easy though?
>>>
>>> If the plan is to provide a global solution, is it a good idea to jump
>>> the gun with hard-wired fixes to particular applications?
>>>
>>
>> I was thinking that CONVERT should make a history component anyhow.
>> Principal of least surprise. All the other starlink applications propogate
>> history if history is present but CONVERT is special because it doesn't
>> start with an NDF. So if there is any HISTORY at all in the input FITS file
>> does the output NDF have a HISTORY component?
>
> The fits2ndf prologue says:
>
> * Implementation Deficiencies:
> * - There is no propagation of arbitrary FITS HISTORY headers to
> * the NDF's history records.
> * - There is no support for FITS World Co-ordinate Systems.
>
>
> First bullet answers your question. Second bullet seems a bit wrong...
>
> I'll look into enabling default History creation in fits2ndf.
Done it.
David
> David
>
>
>> Tim
>>
>
|