NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
One of the keys to success of NetCDF has been the community defining "conventions" that detail the structure of NetCDF files for certain types of data. To date, grids, METARS and RAOB data have well-defined and accepted community conventions. I believe it is in everyone's best interest to continue this approach and serve up data in NetCDF that adheres to these conventions. In addition, as extensions (new point data?) or new forms (satellite data?) are uncovered, community conventions should be quickly defined, with the understanding that the conventions will evolve (for example, CF conventions continue to evolve). Without these conventions, we face a continuation of the current state of anarchy that causes users to spend way too much time and energy "dealing with data formats" and not addressing the real issues. In fact, even when dealing with csv or xml, it is essential that the community establish conventions that prevent data providers from doing things like: a) not defining units, b) not specifying missing values, c) not making the files self-describing by specifying metadata in separate files, etc. (recently, I got a file with "station names" that required the use of an external file to locate these in space and time -- because the stations move). tom On 7/23/07, Ben Domenico <Ben@xxxxxxxxxxxxxxxx> wrote:
Hello, One of the issues confronting GALEON is the appropriate mechanism for serving point data of the sort that is collected by weather reporting stations. It could also be ocean buoys or river gaging stations or air quality monitoring stations, but at Unidata we work with a lot of real-time weather data so that's easiest to experiment with. As part of the THREDDS Data Server NetCDF subset service, there is now an option to use a browser interface to request a subset of the real-time weather station observations on our motherlode server: http://motherlode.ucar.edu:8080/thredds/ncss/metars/dataset.html In addtion to several options for specifying parameters, spatial bounds, and a time subset, one can also request different output formats: -- "raw" is the form in which the METAR observations are transmitted -- "xml" is a dialect of xml that's reasonably easy to decipher -- "csv" is comma separated values -- "netCDF" is a special netCDF encoding for this type of data From the GALEON point of view, an interesting question is whether it makes sense to try to serve this form of netCDF data via the WCS interface. Or is it more appropriate to use the WFS or SOS interface for these data collections? It would also be interesting to know whether any of the GALEON clients would be able to work with the netCDF-encoded data delivered by such a server via any of the interfaces. Your thoughts on these issues would be appreciated as well as reports on any experiences you have in attempting to work with the resulting netCDFs. -- Ben
-- Tom Whittaker University of Wisconsin-Madison Space Science & Engineering Center (SSEC) Cooperative Institute for Meteorological Satellite Studies (CIMSS) 1225 W. Dayton Street Madison, WI 53706 USA ph: +1 608 262 2759
galeon archives: