This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> > 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