[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Support #DBA-325332]: Re: [netcdf-java] announce: release candidate 2 for N etcdf-Java library version 4.0

> 
> John Caron wrote:
> 
> >> I was hoping that I could pull off a generic csv ascii output including
> >> sequences, but I got lazy (and agile) and did the simple thing that
> >> works. It's interesting that Nathan suggested that I need to modify
> >> opendap.servers.ascii.asciiSeq.java. It turns out that my code was using
> >> opendap.servlet.AsciiWriter which has your name on it. My server now
> >> extends AbstractServlet and overrides doGetASC to use my extension of
> >> AsciiWriter.
> >
> > I think i just helped them refactor how they handle ASCII requests.
> >
> >> Is the current ascii format for Sequences written in stone? If a csv
> >> friendly format would be preferred, I might be inspired to make it more
> >> general and contribute that.
> >
> > Its really an opendap thing - they are / were mimicking the way that the C 
> > server does output. You
> > could ask them, and we may be able to figure out how to allow 
> > customizations at that level. I know
> > they have some ideas for "file out" capabilities.
> >
> 
> It sounds like they are open to a different ASCII output format.
> 
> I'm thinking that java properties could be used to map an extension
> (e.g. "ascii") to an implementation of some type of Handler.
> 
> For "file out" do you mean to stream the data file itself? I'd like to
> be able to use a "nc" extension and have it return a NetCDF file (or
> whatever based on mime type) even if my data live behind an NcML file
> via an IOServiceProvider to my database. I figure that we ought to be
> able to support any format for which we have an IOServiceProvider with
> an "O" implementation. Given the idea in the previous paragraph, I would
> have a property that maps the "nc" extension to my NetCDFHandler.

thats s good idea. the problem is that its possible to create CDM datasets that 
cant be written to netcdf-3, and we dont support netcdf-4. we are considering 
how to proceed.

> 
> > Weve been working on "Netcdf Subset Service", which allows lat/lon bounding 
> > box requetss, and can
> > output CSV. Dunno if thats interesting to you.
> >
> > http://www.unidata.ucar.edu/projects/THREDDS/tech/interfaceSpec/StationDataSubsetService.html
> >
> 
> I'll have to take a look at that at least for API related ideas. My life
> is pretty easy right now dealing only with time series of scalars,
> vectors, and spectra. No geo-referencing and such, though one of these
> years we may need Mars geo-referencing!

sign me up.

> 
> >>
> >> BTW, has anyone tried putting THREDDS catalogs in an XML database like
> >> eXist?
> >
> > I havent heard of anyone doing that. CDP keeps metadata in a database, and 
> > generates catalogs from
> > it. But i think its a RDBMS, not an XML database.
> >
> 
> I've done some work with VxoWare (a project of Bob Weigel) which stores
> SPASE metadata (the NASA Heliophysics "standard") in an eXist database.
> We'll see how inspired I get.
> 
> Thanks,
> Doug
> 
> 


Ticket Details
===================
Ticket ID: DBA-325332
Department: Support netCDF Java
Priority: Normal
Status: Closed