netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
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