Hi Joe,
As part of our Time Series Data Server (TSDS), I have created generic
IOSPs for JDBC and other data sources. These, however, are limited by
the simplifying assumptions of the TSDS data model (i.e. time series).
The trick was to set the NcML "location" to "/dev/null" (or a dummy
file) and encode properties (such as JDBC connection string) in the
"iospParam".
We'll be releasing the TSDS on SorceForge very soon.
Doug
On 3/27/10 2:02 PM, Joe Sirott wrote:
Hi John,
A pure CDM interface would be very useful for adding data stores that
aren't based on files (for instance, relational databases or non-OpenDap
network protocols). I worked on a project that required this a few years
ago. All of the data in this project (in-situ atmospheric chemistry
data) was stored in a relational database, and I wanted to use Web
server software (Dapper/DChart) that was built on the netCDF-Java
library. So I created interfaces from the netCDF library, and
implemented concrete classes that were derived from the interfaces to
access the RDB. This was tedious, but it allowed me to reuse all of the
code that I had already developed for Dapper with relatively minor
changes. I wouldn't have had to do this at all if there had been a CDM
interface. And I don't think that an IOSP would work because it requires
random file access.
I realize that the netCDF-Java API is still evolving, but the API has
been around for quite a few years now -- long enough to refactor some of
the CDM API into interfaces. And, at least for me, some stability in the
interface(s) would be welcome, so my code doesn't break every time there
is a version upgrade.
- Joe
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/
