[fitsbits] start of Public Comment Period on CONTINUE Long Kwd convention

[van Nieuwenhoven, Richard]

Hi,

for me the question is more why not, it does not bring more complexity.
and uses the same principle with every card.

Again I am no fits user (aside of an amateur ccd image here and there) I
am just bringing request's of our users.

   Ritchie


Am 2015-06-25 um 04:43 schrieb William Pence:
> Hi Ritchie,
> 
> Your suggestion of how to continue the comment in long string keywords
> over additional null string CONTINUE keywords is quite clever.  I will
> probably steal this idea and implement it in the next release of
> CFITSIO.  I also support the suggestion to add an example to the
> documentation about this convention that illustrates this usage.
> 
> However, I doubt if there would be much support for extending this
> convention to other keyword data types (where the value can easily fit
> on a single header keyword) simply to be able to continue the comment
> field over multiple keywords.  For one thing, the keyword shown in your
> example, namely
> 
> INTKEY  = 1245678901234&  / Optional
> 
> does not conform to format of any of the currently allowed keyword data
> types.  My impression is that most FITS users find it quite acceptable
> to simply write a long comment over multiple COMMENT keywords, often
> times just preceding the keyword itself.
> 
> regards,
> Bill
> 
> 
> On 6/24/2015 2:29 AM, van Nieuwenhoven, Richard wrote:
>> Hello,
>>
>> first a small introduction because I am new in this mailing list. I am a
>> developer of the java nom-tam-fits library (of Tom Mc Glynn). Together
>> we moved the nom-tam-fits library to github
>>
>> (https://github.com/nom-tam-fits/nom-tam-fits)
>>
>> where we are now working to adapt the library to the current needs of
>> the users. Excuse my bad English but I am not a native speaker.
>>
>> One of the issues we have struggled with in the last months is the
>> longstring behaviour together with the possibilities of long comments.
>>
>> Our users where wondering why so much of the comments is thrown away
>> depending of the length of the string. When a string almost fills up the
>> space the comment is "gone" (with longstrings enabled it happens every
>> time all the cards are "filled" with data.
>>
>> Now we found a "hack" in the specification to allow keeping longer
>> comments by splitting the string over multiple lines even is there would
>> be enough space for the string in less cards. then spread over multiple
>> lines there is enough space also for longer comments.
>>
>> In the current specification I did not wanted to go to extreme
>> situations by using string continues like this:
>>
>> STRKEY  = 'This is a very long string keyword&'  / Optional
>> CONTINUE  '&' / very very long comments that must be
>> CONTINUE  '' / split over a very big amount of lines
>>
>> because I can imagine that other implementations would not expect such
>> "strange" usage. But if the new specification explicitly includes such
>> an usage it would be a great help for the developers.
>>
>> My next proposal is to rename the long-string feature to a long-value
>> standard. Why limit long values to strings? Why not use it for all
>> values?
>>
>> INTKEY  = 1245678901234&  / Optional
>> CONTINUE  567890& / very very long comments that must be
>> CONTINUE  / split over a very big amount of lines
>>
>> That would not only allow for values with an unlimited level of
>> precision but also for very long comments. The COMMENT keyword is no
>> alternative here because it can not be automatically detected if the
>> COMMENT has a relation to the previous card.
>>
>> The same accounts for the COMMENT keyword. Currently the comment keyword
>> states a COMMENT with no possibility to write a comment that expands
>> over multiple lines and distinguish (automatically) it from multiple
>> separate comments.
>>
>> So in short I propose to officially allow:
>> 1. empty string value continues to store longer comments
>> 2. use the "long" technique for all value types
>> 3. extend the long technique to the COMMENT keyword.
>>
>> Any thought’s on these feature requests? I am no expert on the standard,
>> just an open source developer grown into the standard, so it could be
>> that I have overseen other possibilities to achieve the user requests.
>>
>>     Ritchie
>>
>> _______________________________________________
>> fitsbits mailing list
>> fitsbits at listmgr.nrao.edu
>> https://listmgr.nrao.edu/mailman/listinfo/fitsbits
>>
> 
> 


-- 
BSc Richard van Nieuwenhoven
Software Architekt

adesso Austria GmbH
floridotower 26. Stock              T +43 1 2198790-0
Foridsdorfer Hauptstr. 1            F +43 1 2198790-13
A-1210 Wien                         H +43 664 88614710
                                    E richard.vannieuwenhoven at adesso.at
                                    www.adesso.at
-------------------------------------------------------------
         >>> business. people. technology. <<<
-------------------------------------------------------------
adesso Austria GmbH mit Sitz in Wien
Handelsgericht Wien FN231467v