WCS Change Requests

From Datafedwiki

S. Nativi, L. Bigagli and P.Mazzetti

1. Coverage format negotiation support is scarce. A server can only advertise the supported formats on a global basis (in its capabilities), but actually the supported formats may depend on the very request: e.g. a server may support geoTIFF-encoding only if requested 2-D subsets of its coverages.

2. The list of preferred standard formats may hinder WCS adoption among communities that use different, specialized formats (e.g. netCDF); a possible solution is to support the definition of application profiles, splitting the specification in a general protocol part and a format-specific semantics.

3. About the netCDF semantics as an encoding format, we recommend that the subsets of netCDF encoded coverages returned by a WCS be consistent netCDF files themselves (not just data chunks).

4. The XML vocabularies used in WCS, O&M and GML may be aligned and harmonized, to avoid duplications and ambiguity (we have encountered this problem when trying to publish ncML-GML encoded coverages). In particular, RangeSetType should provide consistent support to composite range sets (aka multiple measurements) and to parametric range sets.

5. The semantics of subsetting, resampling, interpolation and such WCS operations should be independent of the domain axis to which the operation is applied. I.e. spatial and time axes may be modelled uniformly. In fact, a WCS serving model data may conceivably support time interpolation as well as spatial interpolation.

6. Unevenly-spaced grids (geometries where the distance among adjacent points along one or more of the grid axes is not constant; aka irregular grids) should be supported. Such geometries are most common in the Earth Science domain (e.g. acquisitions are seldom regularly-spaced in time).

7. URL GetCoverage replies should be supported, for subsequent retrieval.

8. WCS bindings to HTTP GET/POST and SOAP should be consistent (this is a wellknown issue addressed in WCS 1.1).

9. A standard description of the expected WCS SOAP interface (e.g a WCS wsdl) should be defined, to improve interoperability of SOAP-based WCS clients and servers. We would recommend SOAP service with literal encoding, due to parameters complexity, using either RPC or Document style.