Review-9

My experience with HDF-EOS5 is trivial. Bruce is the experienced one with it. Having not gone to an HDF-EOS workshop in a few years - I'm out of the loop as far as knowing what the real-world thinks about HDF-EOS. I know that, if they ever collide with netCDF to produce a "better than the two parts" product, it would have a potentially very large user base.

--------------------

I think Matt's comments are very valuable and should be included in the response.

For myself, I commend the HDF-EOS5 developer (singular) for hiding most of the complexity of HDF5 from the HDF-EOS5 user. We were able to make our existing subsetter code work (mostly) by simply changing a few function names. However, there was some confusion over string datatypes: Instead of using the "native" HDF5 datatypes, HDF-EOS5 uses its own and converts from one to the other as needed. Unfortunately, HDF5 defined a number of string datatypes, at least two of which were mapped into a single datatype in HDF-EOS5. When converting back to the HDF5 datatype (which was inexcusably required for some calls), the conversion was often wrong, resulting in mangled output files. That problem was supposedly addressed in the latest version of HDF-EOS5, but I have not had time to verify it.

As for HDF5 itself, I find it far too "computer-sciencey". I'm not a data provider, but I understand what they want: Something SIMPLE, EASY TO UNDERSTAND, and EASY TO USE. HDF5, IMHO, fails in all three categories, more so than HDF4, which is why data providers still want to store their data in simple ASCII text files or more compact (and non-portable) binary files. I'm not saying that data providers are stupid or lazy; they just don't want the hassle of learning something new (and often abstract) simply to store their data, especially since the "format of choice" seems to change two or three times a year. (E.g., XML is the hot format now.)