NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Ethan,I see that netcdf-java client is designed to avoid downloading the entire data onto client. Otherwise, in case of a simple fileServer, the client could download the entire data before decompressing it (if it is compressed).
Upendra Ethan Davis wrote:
Hi Upendra, On 6/8/2010 12:11 PM, Upendra Dadi wrote:Hi Ethan, It does help. Thank you very much. Just to confirm if my understanding is correct- the client software deduces whether the URL is an OPeNDAP URL or not by making additional requests to the server and if it is, it requests the data in uncompressed format from OPeNDAP server which the OPeNDAP server would be able to handle whereas other servers wouldn't.Yes. OPeNDAP is a data access protocol that allows clients to request descriptions of the dataset and subsets of the actual data values (more at www.opendap.org). The server must therefore be able to read, understand, and extract the data from the file. Access through the "fileServer" URLs are simple file transfer over HTTP. So the server doesn't have to understand the data file it is serving. (The netCDF-java library actually uses HTTP byte range requests to not get the entire data file. But the server doesn't know anything about the file except for the bytes it contains.) EthanThanks, Upendra Ethan Davis wrote:Hi Upendra, Are the data files accessible from foo.com through OPeNDAP? If so, try using the OPeNDAP URLs in the NcML rather than the file server URLs. With OPeNDAP, whether the source data file is compressed or not shouldn't matter as that is all handled on the server. When accessed through the file server, the client software is reading the bytes from the compressed file over HTTP. When the netCDF-Java library tries to open a non-OPeNDAP HTTP URL, it assumes the resource is an uncompressed file (for efficiency and other reasons). When it tries this on a compressed file, it doesn't recognize the first few bytes of the file as the netCDF header and so fails to open the dataset. Hope that helps, Ethan On 6/7/2010 4:05 PM, Upendra Dadi wrote:Hi, I am trying to aggregate some netcdf files thought ncml. I am getting an error like this when aggregating: Cant read http://foo.com/thredds/fileServer/examples/test.nc.bz2: not a valid NetCDF file. But I am able to open the same file on THREDDS server. Any suggestions on what might be going wrong? By the way, does THREDDS download the entire netcdf file before aggregating? How do I control how long the temporary dataset stays on the server?On 6/8/2010 11:10 AM, Upendra Dadi wrote:Hello, Can someone please help me here with my ncml issue? My THREDDS server is unable to read remote compressed netcdf files present in the ncml files. However, it is able to recognize remote uncompressed files as well as local compressed files. Does ncml working with remote compressed files? Is there a TDS setting I should be looking at? Thanks!_______________________________________________ thredds mailing list thredds@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit:http://www.unidata.ucar.edu/mailing_lists/_______________________________________________ thredds mailing list thredds@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
thredds archives: