GeoServer : Multidimensional WCS
This page last changed on Sep 03, 2008 by apetkov.
This page serves as a summary of the interest in augmenting Geoserver's WCS capabilities to serve 3D or 4D geospatial data. This common desire originates from diverse scientific communities which have a need for coverage servers which operate on coverage types pertinent to the community's discipline. A common data requirement is gridded meterological input, which can be applied in oceanography, climate change, and other scientific disciplines.
Adit Santokhee represents a group currently involved in an effort to expose the methods of the Grid Access Data Service (GADS)Java library as a web service conforming as closely as possible to the OGC's WCS specification. This effort has the scope defined in this attached document. In summary, they would like to support:
The remainder of this page discusses how this might come about.
Wanting to publish large datasets on intelligent servers which are capable of eliminating wasteful network transfers (e.g. by allowing users to query for a particular variable or region) is about as common as the large datasets themselves. Wanting to then plot a specific variable for a specific region on a map with other annotations is about as common as wanting public funding. Nothing illustrates the impact of phenomenon X better than a map. This really helps to explain why study of phenomenon Xis important to your audience (in many cases, the web-surfing public). As such, adding the ability to manipulate large domain-specific datasets to a fully functional map-making machine is a slam dunk. It's one stop shopping for raw data and pretty pictures.
A couple of sites have already sprung up which illustrate the kind of functionality we desire in the long term. These sites all approach the problem of presenting multidimensional data differently.
The OGC Web Coverage Serveris the reference from which all departures must be measured. This is the current standard for publication of gridded data on the web. It represents a first cut at the problem of publishing gridded data.
We will try to adhere to the WCS standard as much as possibleì, however, there is ample evidence that people who wish to publish multidimensional gridded data attempt to add to it, as documented in the GALEON interoperability experimentwebsite. While we have every desire to use the standard as it is, we have no need to repeat mistakes, paint ourselves into a corner, or go out of our way to build something which will change with the next version of the spec. Our strategy is to look at the facilities offered by WCS, determine how it falls short of meeting our needs, and compare with similar facilities in other, more mature, specifications. If possible, we will try to adopt conventions which are legal (if perhaps not "recommended") according to the current specification. Failing this, we will attempt to make minor alterations only where necessary, documenting them with respect to the pristine standard.
An ISO coverage, as defined in ISO 19123, is really any set of features which possess a common description of their attributes. Because the same attributes are located at different spatio-temporal locations, one may view the collection of features as a single conceptual entity. This entity can provide location-dependent values for the attributes it advertises. The component features do not need to be regularly gridded nor do they need to represent continuous values across the domain. The single requirement is that the same quantities are measured at different locations.
This definition of a coverage tends to wash out the distinction between a Web Feature Server and a Web Coverage Server. Both servers serve coverages. However, Web Feature Servers publish discrete coverages and Web Coverage Servers publish gridded coverages (where the horizontal grid must be regular, but other axes (vertical, time, etc) need not be). In both cases, the item published has a spatio-temporal distribution to all of the items published. This definition does help us reinforce the fact that our scope is limited to publication of gridded multidimensional coverages. Publication of other types of coverages is delegated to the WFS.
This section attempts to evaluate WCS 1.0 with respect to our goals. Such an evaluation should give a fair estimation of where we stand and how much work is required.
Thus far, the only standard in OGC's web server suite to run the gauntlet of ISO standardization is the Web Mapping Services Implementation spec. This free OGC standardmight very well be identical to the ISO version, but this is unknown at the present time. What is known is that the OGC version normatively defines the means of specifying multiple dimensions in the context of a WMS.
This is a WMS spec and not a WCS spec. Having said this, the discussion of multidimensional datasets is pragmatic and clear. In terms of how to select data, the
In summary it appears that the standards organizations are finally beginning to address higher dimensionality. In light of this eventuality, we should adopt their conventions unless there is a compelling reason not to. If we find that changes are necessary, the WMS 1.3.0 methodology should be adopted as a baseline and our final solution should be expressed as in terms of departures from this standard.
As of WMS 1.3.0, a server may declare a custom CRS which has not been defined by an authority factory. There are now two types of CRS references. The Label type requires the familiar syntax "authority:ID". Now there is a URL CRS reference. Using the URLreference, the WMS provides a fully qualified URL to a publicly accessible file which defines the CRS in a way that is compatible with 19111. The actual file format to use is not specified. However, if one courageously adopts the convention that GML is the preferred means of describing a CRS from scratch, a means of automatically communicating a complete CRS definition from server to client is now provided.
Simone writes here
* Whitespace is allowed following commas in a list in a <Dimension> element of service metadata
A resolution value of zero (as in min/max/0) means that the data are effectively at infinitely-fine resolution for the purposes of making requests on the server. For instance, an instrument which continuously monitors randomly occurring data may have no explicitly defined temporal resolution.
All dimensions in a service metadata response are server-defined, with two exceptions. The dimensions named time and elevation are special cases predefined as follows:
The time units identifier "ISO 8601" refers to the ISO 8601:2000 time representation specified in Annex D of the WMS 1.3.0 spec. No unitSymbol is defined for the time dimension. If a server opts to specify time values in a different representation it shall use a dimension name other than "time" (e.g. "date" or "seconds").The elevation units identifier "verticalCRSid" refers to a vertical CRS as in 6.7.5 of WMS 1.3.0 spec. The unitSymbol attribute shall be chosen to match the units of the specified vertical CRS.
EXAMPLE 1 The verticalCRSid "CRS:88" refers to the vertical CRS defined in B.6 (elevation in meters in the North American Vertical Datum 1988). The unitSymbol "m" would be used.
EXAMPLE 2 The following are some examples of server-defined dimensions:
Dimension declarations are inherited by enclosed Layers, as specified in 22.214.171.124 of WMS 1.3.0 spec.
A layer may provide a dimension declaration that has the same name attribute (case-insensitive matching) as a declaration in another layer. However, the dimension shall not be re-declared using the same name with conflicting units or unitSymbol attributes. Extent values, and the attributes default, nearestValue and multipleValues, may be different for each layer.
Some geographic information may be available at multiple elevations (for example, ozone concentrations at different heights in the atmosphere). A WMS may announce available elevations in its service metadata, and the GetMap operation includes an optional parameter for requesting a particular elevation.
where, depending on the context, "value" can be a single value, a comma-separated list, or an interval of the form start/end without a resolution.
To request a particular time from a dataset, the dataset must have the special "time" dimension associated with it. This association is described in the "How to Advertise Dimensions" section above. In essence, declaring that a layer has the special dimension "time" tells the server that "TIME=" parameters in a getMap request apply to this layer. Conversely, all layers which do not have an association with the "time" dimension are considered constant with respect to time and consequently ignore temporal parameters in queries.
Section C.3.6 in the WMS 1.3.0 specification contains two examples of GetMap requests which include time as a parameter. These are repeated here for convenience. The first example requests a single time slice as a GIF, and the second example specifies a range of times to be returned in a movie format (mpeg). These examples assume that "ozone" is a collection of 2D ozone maps at a particular elevation (this is a slight modification from the example in the standard.)
Note that the BBOX parameter does not attempt to address the temporal request. It is purely spatial, and purely 2D (even if we were talking about a 3D data set.)
Sample dimension parameters allow the client to request a particular layer along one or more dimensional axes other than time or elevation.
A request parameter name is constructed by concatenating the prefix "dim_" with the sample dimension Name (the value of the name attribute of the corresponding <Dimension> element in the service metadata). The resulting "dim_name" is case-insensitive. The use of the "dim_" prefix is to avoid clashes between server-defined dimension names and other request parameters defined by this International Standard. (The "time" and "elevation" dimensions, being predefined, do not use the prefix.)
To include a sample dimension value in a request URL, the dim_name parameter is followed by an equals sign "=" and a valid value, a comma-separated list, or an interval, as described in Table C.2 of WMS 1.3 spec.
EXAMPLE A WMS Layer is described as having an extent along a dimension named "wavelength" as follows:
A GetMap request for a portrayal of the data at 4000 Angstroms would include the parameter "DIM_WAVELENGTH=4000".
The WMS 1.3.0 specification supports the notion of a sample dimension, but how exactly is it applicable to our problem? Can we define a sample dimension which contains arbitrary, unrelated quantities like salinity, temperature, etc? Or must we define an axis for each quantity (e.g. a temperature axis, a salinity axis, etc.)? (This second option does not appear to be too useful, and probably is not possible.)
An alternative data representation would be to expose each variable as a separate coverage with it's own units.
We must investigate how to use the sample dimension capability.
As GeoTools does most of GeoServer's behind-the-scenes work, the developmental [ISO coverage implementation]will be relevant to this GeoServer enhancement. This, however, is envisioned as a long term infrastructure investment and not a short term solution.
Phase 1 of the GALEON IE is complete. Copied from The OGC's GALEON page, this experiment was to determine whether:
In the above, THREDDS and OpenDAP are web publishing mechanisms currently in use for large datasets, typically in Grib, NetCDF, or HDF format. NetCDF and ncML-GMLare transfer mechanisms under investigation. Lastly the experiment investigates a number of issues surrounding the expansion of the WCS spec itself.
This interoperability experiment pertains to the web interface presented to clients. It does not traffic in internal details. It is therefore highly relevant when we start to consider what wemust add to the WCS spec. In particular, now that Phase 2 is commencing, it may very well be pertinent to note that one of the objectives is to increase the number of datasets served.
All projects need requirements. That's how you know when you're done. This project will:
The objective of this effort is to implement an efficient and secure publishing and mapping mechanism for nontraditional GIS layers, such as meterological grids. This effort, as it is being led by Adit, will meet his needs. However, we may be able to leverage the previous work by the GALEON IE and the normative methods of OGC WMS 1.3.0 in order to avoid dead-ends. This effort is not part of the GALEON IE, nor is it an OGC effort.
A previous section identified constraints, weaknesses and strengths of the existing WCS 1.0 specification. This section outlines what we intend to do in order to accomodate the weaknesses and constraints.
This effort has at least two independent components:
It's worth noting that with a 4-d dataset, there are:
2. All behind-the-scenes work needed to service requests.
In the near term, the interface of the augmented WCS needs to be nailed down and formalized. This is gives implementors (not necessarily Geoserver implementors) a means of writing interoperable code. In my ([~firstname.lastname@example.org]) opinion, this interface should be as close as possible to the WMS 1.3.0 methodology because I believe this stands the best chance of future-proofing our effort. If possible, electing to not use fancy options (asynchronous data delivery or security) should reduce to the WMS 1.3.0 strategy.
Previous work is documented on the GALEON website and in documents attached to this page. The GALEON documentation appears to be in the form of final reports from individual participants. We should probably review responses from all the participants and combine with the extra requirements of security and asynchronous data delivery to synthesize a good "next step". We should probably strive for a minimum departure from the WCS spec so that it still functions with plain old 2D data...
Watch this space.
The short term solution is to not do anything inside GeoServer itself. All requests will be relayed to an external GADS server and sent back to the client. (Is this correct?)
|Document generated by Confluence on May 14, 2014 23:00|