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.
NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/06/11 15:30, Horne, Randy (Contractor) wrote: > Dear Sir: Dear Randy, > I am working a program where valid gridded data is restricted to the > portions of the earth that are (1) land or sea, (2) day or night, and > (3) clear or cloudy. > > Substantial efficiencies are gained by storing only tiles with valid > data. For example storing land surface temperature in tiles that > only are on land. I am no expert on the matter, but I would store each set of tiles in a different band, each having independent lon/lats. Otherwise, I am pretty sure that netcdf4/hdf5 does a good job at compressing the data if large areas of it are NaNs for example, so maybe it's worth trying ? > In addition, there is substantial benefit in being able to read only > those tiles from a hemispheric netCDF4 file that are requested by the > user. For example, the user may only be interested in land surface > temperature over Argentina in a product that has land surface > temperature for the entire western hemisphere. That is a matter of programming I think: the program must be able to explore and return the interesting data. > A few questions: > > (1) Does one or more existing set of netCDF4 conventions exist to > provide these capabilities ? > (2) If there is not an existing set of conventions, is anyone working > on the conventions required to support these capabilities ? The conventions are merely a naming scheme, nothing more. You can do whatever you want with them, but the capabilities you are are requesting are more programmatic... Best regards, Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN7cJ6AAoJEBdvyODiyJI4RQAH/0DXQftJMw389fTcLpEWU6Fr SNAMuMWX0UBd0DFsbfDmMETwX5u9Gsl8Cdg6slxDynaigKoB3Qrn5+JhKlFdPf2L ANBp8WGQ95YFn0epG+Fj4M2SXRyhcGNf0pt1/m1ZgedWrfI/iuKRxdvIKY6EcYSs mrnQ2Gdy81rW8TuCyLRvTPFV+cJYJqaFwA48EwrdN3lOsBNmw7WCTODKj3tkoFJd anQsYREL1ggotfLcCAHb75Si6ddO3MMeI7j19NlJdvkDLnzSnxp3y0gxNduAK60Z PCJTlPq4pYS+YAiFjelZ4SD7dTSqx5V2THuLVTKTp1oBJCLTF3gR5f50LmwTYfw= =hyZ0 -----END PGP SIGNATURE-----
begin:vcard fn:Martin Raspaud n:Raspaud;Martin org:SMHI adr;quoted-printable;quoted-printable:;;Folkborgsv=C3=A4gen 1;Norrk=C3=B6ping;;60176;Sweden email;internet:martin.raspaud@xxxxxxx tel;work:+46 (0)11 495 8261 tel;cell:+46 (0)11 495 8261 url:www.smhi.se version:2.1 end:vcard
cf-satellite archives: