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 1
of 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