2009/9/11 Tim Jenness <[log in to unmask]>:
> I agree that NDF history should now be enabled by default for everyone but
> I'd like a way for people to get the old behaviour through an environment
> variable. That doesn't seem like it would be a lot of work but I don't know
> much about the NDF library and it's not an immediate priority for David to
> implement this. It could do with some testing to make sure weird things
> don't start turning up in the history.
>
> I haven't been advocating trying to parse FITS HISTORY blocks.
Sorry. When you said "A more middle ground fix requiring more work
would be for HISTORY recording to be enabled if an incoming FITS file
has any HISTORY headers at all. Else, since disable HISTORY if there
is no previous history" I took this as meaning you wanted the FITS
history records to be propagated into the NDF history component.
David.
> Tim
>
> On Thu, Sep 10, 2009 at 6:57 AM, Malcolm J. Currie <[log in to unmask]>
> wrote:
>>>
>>> Just to clarify things, there are two issues being discussed here:
>>
>> I thought it was more than two issues. The other is what to do about
>> other tasks that create an NDF ab initio, such as those I mentioned in
>> KAPPA, Figaro, and other CONVERT x2NDF tasks. That's an addendum to
>> Issue 1).
>>
>>> 1) Whether fits2ndf should produce a History component in the output
>>> NDF that records the fact that fits2ndf has been run (and will also
>>> record all subsequent processing).
>>>
>>> 2) Whether, in addition to 1), fits2ndf should also read any history
>>> information from the input FITS file and add it into the History
>>> component of the output NDF.
>>
>> This hasn't be a priority since (as Tim pointed out) this information
>> isn't lost. The original FITS headers are stored in the FITS airlock
>> of your NDF, and are visible via KAPPA:FITSLIST. Yes it would be more
>> convenient to just run HISLIST to view the entire history, but hitherto it
>> hasn't been flagged as sufficiently important to implement it. One problem
>> is to know how to break up various steps listed in HISTORY headers for what
>> is arbitrary text. We could just lump contiguous sets of FITS HISTORY lines
>> as a single NDF HISTORY record.
>> It's the fact that we don't have the semantics to interpret these headers
>> into NDF form is why they're placed in the FITS airlock, just like most FITS
>> headers.
>>
>>>> It is rather "frustrating" to find the
>>>> HISTORY missing as the only time most people are going to notice it
>>>> missing
>>>> is when they explicitly need it. It seem odd to me, again as a user, to
>>>> have
>>>> a rather useful bit of functionality turned off by default.
>>
>> I agree. As I explained it's historical. (-: It's not clear whether we
>> have the effort to tackle it properly rather than apply the change David
>> made in 1) task by task as demanded.
>>
>>>> How many fits files actually have HISTORY components? If its "not very
>>>> many"
>>
>> Quite a high proportion. It depends on the institution and the
>> culture. It is most common where data are not raw and have been
>> manipulated by a data-processing pipeline. Thus public surveys, space and
>> radio data generally have HISTORY. However, that's not the sole use.
>>
>> Malcolm
>
>
|