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

[THREDDS #MWS-288646]: Metadata from NetCDF files

Hi Estani,

> 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.

Ethan
 
> Regards,
> Estani
> 
> 
> --
> 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 Details
===================
Ticket ID: MWS-288646
Department: Support THREDDS
Priority: High
Status: Closed