NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Ben et al. For your consideration, here's a link to an SOS providing weather station data: Capabilities: http://vast.uah.edu:8080/ows-dev/weather?request=GetCapabilities GetObservation request (1 day's worth of observations): <http://vast.uah.edu:8080/ows5-dev/weather?request=GetObservation&version=0. 0.31 &offering=WEATHER_DATA&time=2004-04-01T05:00:00Z/2004-04-01T06:00:00Z &format=application/com-xml> http://vast.uah.edu:8080/ows5-dev/weather?request=GetObservation&version=0.0 .31 &offering=WEATHER_DATA&time=2004-04-01T05:00:00Z/2004-04-01T06:00:00Z&format=application/com-xml
One of the drivers for the om:Observation schema using SWE Common data types and encoding definitions, is that it would support a wide range of observation types (single observations, time series observations, and coverages such as grids and images) in the same way and in an efficient manner. They are also meant to be self-describing without relying on community-specific agreements. The Observation schema using SWE Common also supports true binary and simple MIME types (e.g. JPEG) through out-of-band links to flat files or within SOAP messages with attachments. However, it is not expected or intended to simply describe and point to a NetCDF or EOS-HDF file, since those can themselves have complex structures in which knowledge of the format is required. We currently have SOSes that utilize NetCDF as the data source, but subset these files at the server level and repackage them as om:Observation. All of this discussion again brings up, of course, what we discussed in Paris ... the need for the various web service groups (SOS, WFS, WCS) and encoding groups (SWE, GML, NetCDF, EOS-HDF, video, etc) to all begin to meet together for the sake on defining harmonization and/or dividing lines between OGC services and encodings. Thanks. Mike Botts
From: owner-galeon@xxxxxxxxxxxxxxxx [mailto:owner-galeon@xxxxxxxxxxxxxxxx] On Behalf Of Ben Domenico Sent: Monday, July 23, 2007 5:12 PM To: Unidata GALEON Subject: weather station observation data in netCDF 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 observationson 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 datacollections?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
galeon archives: