On 4/28/2010 8:14 AM, Stephen Emsley wrote:
We have multiple satellite geophysical data products which share the
same set of geo-location and timing co-ordinates. To avoid product
bloat (e.g. from approx. 30GB to 90GB per orbit) we are considering
the possibility of having a single file storing the co-ordinates but
we think that this conflicts with our desire to be CF Convention
conformant. Is that correct?
Many thanks
Steve
--
Dr Stephen Emsley *::* ARGANS Limited *::* www.argans.co.uk
T: +44 1752 764289 *|* M: +44 7912 515418 *|* [email protected]
/ /
This message is to be treated as private and confidential, and the
information in it may not be used or disclosed except for the purpose
for which it has been sent. ARGANS is a limited company registered in
England & Wales. Registered number: 6313966. Registered address:
Thatchers, Russells Water, Henley on Thames, Oxon, RG9 6EU
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
There are 2 classes of proposed solutions to this problem:
1) place metadata inside the netcdf files to associate different files
together. Balaji's gridspec (at least some version of it) has a proposal
for this. Other ideas in this category have also been proposed on this list.
2) create an external document that associates different files together.
This is what NcML "union" aggregation does, and Im sure there are other
mechanisms already in use that take this approach. The java-netcdf
library currently is the only code that can deal fully with NcML,
although other projects, including the netcdf-c library, have plans to
add NcML support. The THREDDS Data Server (TDS) makes it reletively easy
to use NcML on a server, allowing remote access.
Each approach has pros and cons. It might be helpful to describe what
use cases we want to cover.
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
