Hi Steve,
I'd like to open another outlook for this entire discussion -- an approach that might meet your goals with no changes to CF at all.
In the detailed use cases that you presented yesterday you motivated the CF changes under discussion by pointing out that it would not be desirable to create multiple files to contain the same data, specifically "... one could of course generate multiple copies of the output file with one auxiliary coordinate system each, but I do not like this approach" What your use case has presented to us (I think) is a case of multiple "views" of the same data: The data variables and their coordinates in absolute lat/lon are immutable. But you also want to support two or three community-specific outlooks, each requiring specialized coordinate system information.
This statement of the problem practically shouts out "service oriented" -- providing different flavors of the same data through multiple interfaces. I think we can achieve that today with existing tools -- OPeNDAP and TDS. Standard netCDF clients can "simply" (in quotes) be relinked to utilize the OPeNDAP service.
Hm, a quite different approach indeed. I have no experience yet with OPeNDAP, my approach so far has been first to get netCDF CF support implemented correctly and take the next step to OPeNDAP. I associate OPeNDAP mostly with data access through the internet. An OPeNDAP compliant reader will allow you also to access local data files, but whether all features are available I am not sure. I know that it is possible in some way to serve multiple files as one big virtual file using OPeNDAP; however, I don't know whether that works also locally and what the requirements are for combining multiple files to one virtual file. I am looking for a local option because
1) model runs may be carried out by different project partners.
2) data files may be big and not easily transferred via internet.
One thing that I am not sure about is what you exactly propose. After some text regarding the immutabel part and special attributes and variables for the two separate communities, you propose:
You can arrange for these views to show up neatly organized in a directory tree
http://my_institution_server/
Germany/
...files...nc
Netherlands/
...files...nc
Would all data be stored in both the Germany and the Netherlands directories (only different with respect to the local grids stored in the files)? If so, that approach would be quite redundant. I don't need OPeNDAP for that and I can just generate both files and distribute them individually, or I could probably write a small conversion program to convert one file into the other using some separate grid files, or use separate grid files in addition to the data file. If the main data is stored in a central directory while community specific extensions are stored in the two subdirectories then I'm not sure how its going to work (only through internet access?, what about the variable specific grid_mapping attributes?).
P.S. (footnote) On the initial point about redundant "grid object" contents: I was referring to situations where variables like velocities (XYZ), share the same horizontal coordinates as variables like streamFunction (XY). The grid_mapping info for the horizontal has to be repeated in both grids ... or alternatively, complexity has to be introduced to represent parent (XY) and child (XYZ) grid objects.
As long as the grid_mapping data sets do not refer to variables, there is no need to duplicate the grid_mapping data. I only see the need to specify for every variable in the file the grid_mapping attribute (current situation) or coordinate_system (one of the alternatives). So far, grid_mapping is a purely horizontal transformation, so, if the velocities are stored at the same grid locations as the streamfunction and the Z dimension is a separate dimension, there is no need to duplicate the horizontal grid variables either. If the velocities are stored at different X,Y locations than the streamFunction then we need of course two grid specifications.
Best regards,
Bert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061206/37ae2c56/attachment-0002.html>
Received on Wed Dec 06 2006 - 01:53:29 GMT
