>From: "Joshua Colwell" <josh.colwell@lasp.colorado.edu>
>To: "Mark Showalter" <showalter@ringside.arc.nasa.gov>
>Cc: "Joshua Colwell" <josh.colwell@lasp.colorado.edu>
>Subject: PDS disk review
>Date: Tue, 10 Jul 2001 10:51:21 -0600
>
>Hi Mark,
>Here are some comments after playing around with the PDS PPS rings
>disk for a while.  I will try to do more.  The following comments are
>mostly very minor, with the only major complaint probably falling
>outside your domain.
>
>In the Catalog directory: the windows operating systems thinks files
>with a .cat file suffix are security catalog files and tries to open
>them with the wrong application.  A note should be put in the readme
>for this directory indicating that the contents of these files are in
>ASCII format and can be viewed with a text viewer. Missing from
>ref.cat is Horn et al. 1990, GRL 17, 1745-1748. In person.dat: change
>Esposito's and Simmons's e-mails to
>firstname.lastname@lasp.colorado.edu.
>

I have added a note to CATINFO.TXT describing the issue about .CAT
files.

I have added the missing reference to REF.CAT.

I have updated the email addresses for Larry Esposito and Karen
Simmons in PERSON.CAT.

>
>In the images directory, the datainfo.txt file does not point to the
>software which can be used to read and view .img files.  Is there some
>easier way to see an image than wading through the 100+ page OAL
>user's guide? If so, please tell us somewhere.

I have added a note to DATAINFO.TXT pointing the user to software
tools for displaying these image files.

>
>In the software/oal/idl directory, the readme.txt file redirects us to
>the OAL user's guide, but doesn't give the location and name of that
>file.

The User's Guide is in the directory above.  I have added a note to
README.TXT.

>
>In software/oal/examples/readme.txt it sas v1.lbl, sgc_0031.lbl and
>sgc_0031.dat must in the directory to run the examples, but I can't
>find those files.  Why not just include them in the examples
>directory?  I don't see a "pub/oal" directory which is mentioned
>there.

This appears to be a severely outdated comment. I have searched for
old copies of the sample files but they appear to be lost. For now, I
have added a note to README.TXT warning users of the missing files,
and noting that the programs can be adapted to run with other PDS data
products. This problem should be fixed in a future release of the
Object Access Library.

>
>Sorcdata directory: no comments.
>
>Rawdata directory: no comments.
>
>Easydata directory: I looked here for easy views of calibration data. 
>I guess that is in the calib directory, but the datainfo.txt or a
>readme in the easydata directory should tell us that.

The EASYDATA/DATAINFO.TXT now makes it clear that this directory tree
contains only calibrated profiles of the ring.

I'm not exactly sure what easy views of calibration data would look
like. The calibration files are already ASCII tables, easily plotted
by the interested investigator.  I have added notes to the files
AAREADME.TXT, DOCUMENT/TUTORIAL.TXT, CALIB/CALINFO.TXT, and also
GEOMETRY/GEOMINFO.TXT to emphasize this point.

>
>Then, in the calib directory, it doesn't contain all the calibration
>files. I was looking for the PS4R01.dat observation of Vega, but it
>seems that only observations of Sig Sgr and Bet Per are included in
>the directory.  I think all of it should be there.

The calibration files are treated as actual data for our purposes, and
are archived along with the occultation data in the SORCDATA, RAWDATA
and EDITDATA directories. I believe this is the appropriate approach
because it guarantees that files with the same format reside together
in the same directories; it would be more confusing to users to find
files with radically different formats mixed together.

I have added comments to CALIB/CALINFO.TXT to direct users seeking raw
calibration data to the correct directories.

>
>Also in the calib directory in calinfo.txt: in Phil's memo, give the
>full reference for "Uranus" chapter by French et al.

I have updated that reference and also the Neptune chapter reference,
Porco et al. 1995.

>
>At the top level in Aareadme.txt, *.pro should be in the list of
>source code files.

Done.

>
>Finally, aside from looking at the easydata I've had a frustratingly
>difficult time getting to look at any other data.  This is largely
>because the software is not friendly to Windows (or apparently linux)
>operating system. The IDL software I looked at is out of date and
>difficult to use.  The embedded comments are cryptic and the OAL
>user's guide is too long.  The IDL code wants a shared library
>oal_idl.so, but this isn't provided - it must be made. But I didn't
>see any directions for making it, and in any event it would be easier
>(for the user) just to provide a built version of oal_idl.so for the
>major platforms.

I regret that you had so much difficulty with the software. In
general, software is rarely included on archive volumes because it has
such a short usable lifetime relative to the data.  Also, it is clear
that the IDL implementation of OAL has not been well maintained.

A new set of programs has been added to the SOFTWARE directory:
DUMPOC1.FOR, DUMPOC1.C, DUMPGS3.FOR, DUMPGS3.C.  They are C and
FORTRAN versions of simple programs to extract records from the
EDITDATA binary files.  My hope is that they will solve the problem
you and others have had reading the binary data files. (Sorry but I
don't know how to write IDL versions.)

I have also tried to make a few changes to enhance the usability of
the software included.  The main change is an added file,
SOFTWARE/OAL/AAREADME.TXT) to guide users through the building of the
C libraries. This is the only step that is necessary for users to
build the PPS resampling and filtering programs, which are the only
supported programs on this archive. I have also modified the Profile
Library to make it easier to build.

Beyond that, I will relay to the Central Node your comments regarding
the IDL interface to the Object Access Library, and regarding the
quality of the documentation.

>
>From an archiving standpoint, it seems to be complete and everything
>connected with the data is apparently very well documented.  I don't
>have any comments on that part, and that is the fundamental part of
>the disk.  But somehow it seems to me that it shouldn't be so
>difficult for me to get a look at one of the images (I have no idea
>how to deal with a VICAR2 image format, and the PDS headers don't
>provide much help, and I can't run the software on my machine).  Now
>I'm actually going to dig into writing my own programs to extract some
>of this information, but I doubt that activity will result in any
>additional reviewer-type comments on the disk.
>
>Josh
>-------------------------------------------------------------------------
>Joshua E. Colwell
>Laboratory for Atmospheric and Space Physics
>University of Colorado
>392 UCB
>Boulder CO 80309-0392
>josh.colwell@lasp.colorado.edu
>Tel: 303-492-6805
>Fax: 303-492-6946
>http://lasp.colorado.edu/~colwell/
>--------------------------------------------------------------------------
>
>
>
>From: "Joshua Colwell" <josh.colwell@lasp.colorado.edu>
>To: "Mark Showalter" <showalter@ringside.arc.nasa.gov>
>Cc: "Joshua Colwell" <josh.colwell@lasp.colorado.edu>
>Subject: additional PDS disk comments
>Date: Tue, 10 Jul 2001 13:59:28 -0600
>
>Mark, the following paragraph, found in the datainfo.txt file in the
>editdata directory, should, I think, appear prominently in the
>uppermost aareadme.txt file to direct people to the editdata
>directory: These are the recommended data files to use for essentially
>all PPS data analysis.  The Rings Node has gone to considerable effort
>to test and identify the reliable and useful segments of the data
>found in the RAWDATA directory.  Further information about how the
>data files were edited may be found below and in the PDS label files;
>see, in particular, the DESCRIPTION fields.

I have emphasized this point near the top of AAREADME.TXT, and also in
DOCUMENT/TUTORIAL.TXT.

>
>
>I've been trying to get some of the software to work.  For PPS data it
>seems like your routines are the ones to use.  So I copied them to a
>Sun workstation.  The first problem I encountered was that ftp-ing in
>binary mode appended an invisible CTRL-M to the end of every line
>which makes all the compilers barf.  So I retransferred in ascii
>format. The documentation file assumes a relatively high level of
>computer programming knowledge on the part of the user.  Is an
>idiot-proof step-by-step tutorial beyond the scope of a PDS disk like
>this?  If not, it would be helpful here, and then at the highest level
>aareadme.txt file a pointer to it so that a first time user is walked
>through the steps of getting the data from some editdata file into a
>format they can look at (Excel, IDL, or just an ASCII printout).  Next
>I had to chmod +x on all files.  I'm now at the point where it isn't
>compiling because it isn't finding oal.h which is required by some of
>the files in the PROFILE directory, but which is not included in that
>directory as well.  I would recommend having all files which are used
>by a particular set of routines located together.

Thanks for your comments. There's not much I can do about the CTRL-M
problem, it is a fact of life when moving files between modern
hardware.

SOFTWARE/OAL/AAREADME.TXT now provides a very brief description of how
to build the Object Access Library. Also, the build instructions in
SOFTWARE/PROFILE/AAREADME.TXT have been clarified. Also,
SOFTWARE/SOFTINFO.TXT now directs the user to both of these files
AAREADME files.

In addition, as noted above, much simpler sample programs are now also
provided in the SOFTWARE directory.

>
>Josh