Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Hi Doug,At IFREMER, we are now developping a server for in-situ datasets which aims at managing plugins 1. for reading datasets: netCDF/Argo, OceanSites, RDBMS (we call them 'storageUnits') and 2. to disseminate datasets : OPeNDAP/DAPPER, OGC/WFS (we call them 'frontDesks').
These plugins exchange observations data according to a data model inspired by CSML (http://csml.badc.rl.ac.uk/) and CDM.
As the server is developed with a model driven architecture methodology (code is generated with androMDA), the data model for our observations is available in UML.
You can browse it from :http://www.ifremer.fr/isi/oceanotron/umlVOReport/oceanotron_umlSimpleReport.html (package ocsml, may be it's not up to date and it can evolve as we are still developping).
Our project page is : https://gforge.ifremer.fr/wiki/doku.php?id=oceanotron:start
As we needed to develop from the UML, we had to "redraw" this data model as neither CSML, nor CDM had one suitable as-is for us. The dataset type we manage are : vertical profiles, time series and trajectories (we focus on in-situ).
If this can help you, either the UML or the generated code are open source. Let me know.
Best regards, Thomas John Caron wrote:
Hi Doug:While there are some simple UML descriptions of the CDM, the real work and thought is in the netcdf-Java library and API. It evolves from the ground up, as we deal with more datasets and data types.In an ideal world, we probably would develop an interface that corresponds to a "pure" CDM description. In the real world, theres not enough resources or motivation to do so. Also, its still evolves, esp at the feature type APIs, and i dont think its time yet to cast that in stone.Can you describe some use-case in some detail? Why would a group "never adopt NetCDF-Java" ? What is the issue there that could be solved by a lightweight API ?John Doug Lindholm wrote:I still intend to focus on Java, but I want to be able to plug in a light-weight alternative to NetCDF-Java. I have a system with a data model implementation that is consistent with the CDM. Instead of writing an IOSP or subclassing NetcdfFile and taking on all of NetCDF's dependencies, I'd like to have a Java Interface that my data model could implement. All "client" code would then write to that interface. NetCDF and other implementations of that same interface would then be usable by that same client.I work with groups that will never adopt NetCDF-Java but they might implement a simple set of Java Interfaces with their data model. This would lower a lot of barriers to interoperability. Is the CDM moving in this direction or is the plan to expose all other data via the NetCDF-Java API?Thanks, Doug On 3/26/10 2:15 PM, Richard Signell wrote:Doug,What is the state of the Common Data Model(http://www.unidata.ucar.edu/software/netcdf-java/CDM/)? Is there a complete definition of the model. The UML on that page communicates the idea well, but I'd like to see an interface that I could program to. Right now, I amuncomfortably tightly coupled to the NetCDF Java implementation.What other language are you planning to be coupled to? Just thought others in the community might be curious besides me. -Rich_______________________________________________ netcdf-java mailing list netcdf-java@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/_______________________________________________ netcdf-java mailing list netcdf-java@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
-- ------------------------------------------------------------- Thomas LOUBRIEU IFREMER IDM/ISI BP70 29280 Plouzane FRANCEemail: Thomas.Loubrieu@xxxxxxxxxx
WWW : http://www.coriolis.eu.org/cdc Tel.: (+33) (0)2 98 22 48 53Fax: (+33) (0)2 98 22 46 44
-------------------------------------------------------------
netcdf-java archives: