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 *|* SEmsley at argans.co.uk
>
> / /
>
> 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
> CF-metadata at cgd.ucar.edu
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20100428/dbe798de/attachment-0002.html>
Received on Wed Apr 28 2010 - 09:31:18 BST
