[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: file naming
Arne and all,
I am anxious to settle on a file naming convention for the Mark IV
data. At this point I am only interested in naming the raw files. So a
processing step identifier is not required.
1) I am willing to live with an 8x3 format.
2) To be compatible with readers a fits extension is needed. I guess this
means the extension is .fts/fit which?
Arne and I at least need a site in the file name to keep data straight
between cameras. So I propose:
dddfsnnn.fit
3 digits of Julian date
f for filter
s for site
nnn sequence number for the evening
I will have 3 site names and Arne will (eventually) have two. Or we can
have CHRIS be the site name for the second camera at NOFS. There are
enough letters since I plan to build at most 20 systems. In any case, a
site is necessary for "at a glance" identification of data. That is by
looking at the file name. Since we now have fits headers, everything else
one might want to know is found by reading the fits header. I thus see no
normal reason for a directory on the CD. But I would not object. Arne,
for example, might want to take data on several different fields during the
night. He then might want to create a separate directory for each
object. Seems OK to me. My plan is to do mostly survey work. I tend to
run one long sequence.
I will actually write files with the fits ending because my copy of DS9
demands it. I will then do a global edit on the extension when I send data
to others.
What say everyone?
Tom Droege
At 11:03 AM 6/14/01 -0700, you wrote:
>Tom recently suggested that I take an active part
>in any file naming discussion, since I wrote a TN
>on the process a while back. That technical note
>was concerning the Mark III data, a much more limited
>project.
> My feelings towards the Mark IV have already been
>stated:
> (a) files stored on CDROM should be in an 8x3 format
> so that they obey the ISO 9660 standard.
> (b) if you need more characters than that to uniquely
> identify the data, then you should use a directory
> structure on the CDROM.
>
>I've never been a great fan of including the 'time' as part
>of a file name; the number of characters necessary to obtain
>a unique name depends on the exposure length. I have always
>been a great fan of a sequence number, so that automated
>processing tasks can easily access the files.
> The ways most professional observatories name files
>usually falls into two categories:
> (1) a filename based on the name of the observed field,
> such as ngc4449.fit. This can get long if you
> start including filters, sequence numbers, on/off sky, etc.
> (2) a filename based on the UT date plus a sequence
> number. Examples are y01d138.005, 990504.101,
> j1520f233.fit (where the last one is based on the
> last 4 digits of the Julian Date plus a 3-digit file number).
>
>So if I were to state a preference at this stage, I would
>suggest the following:
> (1) use a directory structure on the disk, where the
> upper level directory indicates the site. How the
> site is to be named is TBD; perhaps by the system
> 'name' like TOM, MIKE, etc.
> (2) under the site directory, use a unique filename with
> a sequential file number. I would suggest
> jddddxsss.fit
> j -- indicates following digits are Julian Date
> dddd - last 4 digits Julian date (9999 days is longer than
> these systems will run)
> x -- single character of filter name (bvri)
> sss - 3 digits sequence number, starting at 000
> (1000 files should be plenty for a Mark IV)
>
>My personal data is stored in a similar manner, though the
>file names look more like
> yymmddfx.sss
> yy - (year - 2000)
> mm - month
> dd - day
> f - filter name
> x - processing step (r=raw, d=darksub f=darksub&flatfield)
> sss - sequence number
>but I understand that this does not uniquely identify the files
>as 'fits' and some processing programs can't handle it. I prefer
>my format since I think in yymmdd instead of jdddd.
>Arne