Design

• To: cc *.c -L/usr/local/lib -lhdf
• Subject: Design
• From: cc *.c -L/usr/local/lib -lnetcdf
• Date: Thu, 7 May 1992 9:42:49 MDT

I just skimmed the design draft that you posted. This project is definitely
needed and should provide access to a lot of neat stuff on both sides of the 
fence.

I do have some comments. Unfortunately my printer only printed the first 
five pages so I appologize if some of these issues are covered after page 5.

First and most importantly, I'd like to comment on the two requirements listed
on the first page.

>"Firstly, that the resulting interface be call coompatible with the existing 
>netCDF implementation; allowing all existing netCDF programs to continue 
>functioning as expected."

Does this imply ALL that files writen using the HDF interface will be compatible
with programs using the netCDF interface? Seems improbable.

Will the following be the only change I'll have to make to my programs?:
 

Will netCDF files written using the unidata library be accessible to programs
using the HDF-netCDF library and visversa? Seems impossible. This conversion 
problem needs to be addressed.

Explicit information should be outlined on exactly what is expected when:
A file written by unidata's is read by HDF.
A file written by HDF is read by unidata's.
A file written by HDF is read by netCDF-HDF.
A file written by netCDF-HDF is read by HDF.

>"And secondly, that the resulting files be true HDF files in that they will 
>be recognizable and readable by existin HDF tools. It is to be expected, 
>however that not all of the HDF tools will know how to intelligently process 
>all of the information in the new files immediately."

It is surely the case that not all netCDF programs will be able to read 
images in a 24-bit format or understand what to do with them. Some comments
are needed on the subset of HDF data types that will be recognizable from 
programs using only the netCDF calling interface.


Your overview of the data models is not an overview of the data models. Its
a compare and contrast section. I suggest that you do not mention the other
library in each of the overview and write another section comparing and 
contrasting the two.

Very little was mentioned about RANDOM ACCESS (Hyper-Slabs) IMHO this is the
most important feature any storage format should. It is the only way that 
EOS datasets will be accessed. This is one of the most important earth 
observational satelites and the GIGABYTES are going to be flowing in less than
two years. You claim that netCDF programs will have access to image data 
through netCDF-HDF. Does this mean you plan to implement RANDOM ACCESS for 
images? My brief scan of the HDF 3.1 doc doesn't reveal that this is currently 
possible unless the data is an SDS.

I wouldn't knock the XDR and transparency issue. Although slow people are 
actually able to read files, written on a CRAY, on a MAC! What will the behavior
of netCDF-HDF be if these same people switch to netCDF-HDF? Data vendors are
considering writing CD-ROMS in netCDF solely because they only have to stamp
one kind of CD.

Well enough for now. I've got to go print the rest out.

In what version of HDF are VGroups and VDatas discussed? What is the current
version number? I have 3.1 and its dated July 90 surely there's been revisions
since then.

        -ethan alpert



 



-- 
Ethan Alpert  internet: ethan@xxxxxxxxxxxxx | Standard Disclaimer:
Scientific Visualization Group,             | I represent myself only.
Scientific Computing Division               |-------------------------------
National Center for Atmospheric Research, PO BOX 3000, Boulder Co, 80307-3000

• Follow-Ups:
  • Design
    • From: Russ Rew