I think its a mistake to promote the use of a proprietary compression scheme, unless it was much better, which i doubt it is. If the szip patent holders would like to release their IP claims then that would be another matter.
I also think its fatal that theres no java implementation, and theres doubt whether one could legally be written. We would then be in the position of writing netcdf-4 files (by the C netcdf library) that cant be read by the java netcdf library.
OTOH, trying to read existing szipped data is a good thing if possible, since
there may be Important Stuff in There, that wants to be set free.
Ted Mansell wrote:
Ed, et al.,
Szip Cons:
* No existing Java version.
* License restrictions for commercial writers of data.
* Some (or most) netCDF-4 installations will not be able to read szipped
files without rebuilding netCDF.
* Will not (and should not) be used by CMIP5 effort and (probably) other
important archives.
* Due to licensing szip will not be available in stock Fedora
distribution. Fedora is a very popular Linux distribution, and at least
some other free software distributions will probably feel the same
about szip licensing problems.
All of these apply equally well to hdf5, so why is it a big deal? szip
is not a default option for hdf5, so probably most folks don't use it,
anyway. I think if you already put it in, it might as well stay in for
those who want to use it and don't need to worry about compatibility.
(I'm sure plenty of commercial software doesn't even read netcdf4 yet,
either.)
As for Fedora users, they should be able to install stuff that they
want. I'm not complaining that OS X doesn't have szip in the stock
install.... get the tar file and go.
If licensing is really an issue, it could be a separate config option to
enable writing of szip (e.g., --enable-write-szip), and let --with-szip
just enable reading.
Is it just a matter of time before the Java version catches up? Not
that I use it....
Best,
-- Ted
_______________________________________________
netcdfgroup mailing list
netcdfgroup@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
