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 am
uncomfortably 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@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
--
-------------------------------------------------------------
Thomas LOUBRIEU
IFREMER IDM/ISI
BP70
29280 Plouzane
FRANCE
email: Thomas.Loubrieu@xxxxxxxxxx
WWW : http://www.coriolis.eu.org/cdc
Tel.: (+33) (0)2 98 22 48 53
Fax: (+33) (0)2 98 22 46 44
-------------------------------------------------------------
