[THREDDS #MWS-288646]: Metadata from NetCDF files
- To: address@hidden
- Subject: [THREDDS #MWS-288646]: Metadata from NetCDF files
- From: "Unidata THREDDS Support" <address@hidden>
- Date: Wed, 30 Jun 2010 12:52:14 -0600
> i was wondering if it is planned to add support for reading directly
> metadata from NetCDF headers (as far as I know metadata has to be
> written directly in the catalogs). We currently read it from the files
> and write it into the catalogs.
We are working or plan to work on automatic metadata harvesting in a few ways.
The first is when we can recognize a dataset as a particular type of data
(e.g., gridded data). Then we will extract information that we know about that
data type like temporal and geospatial coverage. We have this working in our
TDS 4.2 development code for the FMRC aggregations. We plan to extend this to
other types of data (point, station, profile, etc) probably in TDS 4.3.
The second is a more general extraction that doesn't require that we understand
the semantics of the dataset. It will either require that the dataset contains
certain metadata conventions or it will require some kind of configuration in
the catalogs to indicate what netCDF attributes should be harvested and how
they should be displayed in the catalog. This is one of the features we have
discussed for the TDS 4.3 time frame.
What are the use cases that you are trying to deal with? Do the two approaches
I've described above seem like they would cover your situations?
> Something totally different: We've written a filter to provide
> off/on-line access to files (files are retrieved from deep storage on
> demand and cached prior to continue with the servlet call, e.g. openDAP
> or fileServer). Is there any interest in such a filter or procedure? The
> code will be open sourced, although we still have to define which
> license to use (the broader, the better).
Yes, we are interested. Allowing for asynchronous access has come up often in a
number of different groups including OPeNDAP and OGC. A lot of the discussion
there was around how the server and client might negotiate with and notify each
other. Have you thought much about that side of things? Or do you require a
client that doesn't time out too quickly.
> Estanislao Gonzalez
> Max-Planck-Institut fÃr Meteorologie (MPI-M)
> Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
> Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany
Ticket ID: MWS-288646
Department: Support THREDDS
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web. If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.