NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hello All - For those of you who are interested, I thought I would share some of the experiences that our project has had with WCS over the last several months. The Nextgen Network Enabled Weather (NNEW) project, consisting of members including NCAR Research Applications Lab (RAL), MIT Lincoln Labs, and NOAA Global Systems Division (GSD), has recently completed Phase 1of work. One of our goals was to share gridded weather data using the WCS standards
and we've had good success.Each of the labs are sharing their data through OGC WCS servers. NCAR RAL and MIT Lincoln Labs each implemented a (very trimmed down) WCS 1.1 over SOAP server, whereas NOAA GSD is serving their data through THREDDS (Unidata) and WCS 1.0 KVP. The MIT and NOAA datasets are 2D surface fields, whereas RAL datasets are 3D including a vertical dimension. In addition, each dataset (for all labs) has a time dimension. Lastly, NetCDF3 (using the Climate-Forecast or CF conventions) is the data format used/returned
for all getCoverage results.The results of our efforts were demonstrated using a Java Web-Start application written using RAL's JADE library, that is available at: http://weather.aero/nnew/phase1/ if you want to run it. This application is successful in that it demonstrates how easy it is to integrate disparate data sources into a single visualization app using different protocols. The app is designed and configured in such a way that it uses abstractions such as DataLayers, Retrievers, ValueObjects and Renderers. Therefore, it's easy to write classes that use WCS 1.1 SOAP, WCS 1.0 KVP and/or NetCDF3 (or others) that can be plugged in using a variety of combinations. If you run the demo application, you'll notice that it's a 2D application yet it allows the user to select times and altitudes for the slices of interest. Times and altitudes (for 3D) become part of the DomainSubset of a getCoverage request, though probably not in a way that's precisely true to the spec. At the bottom of this email, I describe the various data layers fyi. Another item of note is that the user can define arbitrary vertical cross-sections through the 3D data sets. This is accessible via the "Tools->Flightpath" menu. For these cross-sections, the client requests a volume that encompasses the entire flightpath, and then (client-side!) slices the returned volume in the vertical dimension along
the flightpath. In summary:* Understanding the basics of the WCS 1.1 spec was easy, but understanding the details was (is) difficult, especially the CRSs. It would be very beneficial to have a webpage devoted to describing the CRS concepts that should include geometric diagrams (not UML ;-) conveying
the concepts.* Implementing the WCS 1.1 server (trimmed down) was easy for SOAP, thanks to the Spring Framework, XMLBeans and the distributed .xsd files. Spring allowed us to be woefully clueless wrt SOAP, and the XMLBeans/.xsd files provided the marshalling/unmarshalling
of XML solution.* Performance is good, though you might imagine that going from the client as XML to SOAP then to the server as SOAP to Spring to XMLBeans to doing the data extraction as NetCDF and back, can take some time. Hence DomainSubsetting is paramount to performance (including server-side decimation/sampling, though we haven't implemented this yet because we couldn't
identify if the spec allows this - though one of our members said it does).* Vertical and time components are fundamental to our applications, and most DSS applications
related to aviation.* Again, DomainSubsetting is paramount to our apps. In addition to vertical cross-sections, other arbitrary geometries will need to be extractable for future applications. This may include geometries such as horizontal (XY) cross-sections along a flightpath, cylindrical or rectilinear cross-sections along a flightpath, and even non-rectangular trapezoidal shapes extending in the XY and vertically from a specific location (eg: an irregular volume extending from a point, used as the approach airspace into Denver International Airport). Geometry extraction, especially along a flightpath, will also require a time component for waypoint definitions.
I hope what I have summarized here is useful to the WCS and GALEON efforts, at least in getting a feel for what others are doing with the spec. Feel free to send me issues, questions,
comments and suggestions ;-) - Rob ----- FYI, here's a description of the various data layers in the 'Weather' menu:* In the 'Weather' menu, the layers labeled "Surface" come from GSD, using WCS 1.0 KVP * In the 'Weather' menu, the layers labeled "CIWS" come from LLabs, using WCS 1.1 SOAP * In the 'Weather' menu, the first 6 layers come from RAL, using WCS 1.1 SOAP * In the 'Weather' menu, the layers labeled "Radar" or "NCWD" are not using WCS, and come from RAL
The datasets that are available from the 'Overlays' menu come from RAL, using a MySQL database, and we anticipate that they will come from a WFS server in the future (we hope this fiscal year).
-----Also FYI, here are the servers we implemented/deployed. In no way would these pass
any WCS 1.1 conformance tests ;-) : NCAR/RAL - SOAP WCS 1.1 (not full featured yet): http://weather.aero/wcs/soap MIT Lincoln Labs - SOAP WCS 1.1 (not full featured yet): http://ngentst.wx.ll.mit.edu:8080/wcs-spring NOAA/GSD - WCS 1.0 (THREDDS): http://nextgen.fsl.noaa.gov/thredds/wcs/madis/rsas/MADIS-RSAS-Agg
galeon archives: