NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Dear all,FYI let me post an overview of WCS GetCoverage response (see WCS 1.1 "Response encodings" and Annex).
The encoding of the GetCoverage response consists of a Coverages XML document - the so-called manifest - and one or more result files representing the coverage selected. Alternatively, the "store" request parameter can make the file(s) remain on some server location and have returned URLs pointing to the file(s). The manifest structure only contains the essentials of the coverage result, to be independent from the largely varying and usually (for our purposes) incomplete file format metadata. No file formats have been fixed (in particular: no new ones have been invented), this is left to format specific profiles (netCDF, GeoTIFF, ... - I would extend a warm welcome to GML specialists for establishing a WCS GML encoding profile).
The outcome we humbly hope to achieve is - a crisp, modular, easy-to-use spec- avoiding redundancy when combining WCS with other OGC standards (or other application structures) - avoiding to fix any not directly WCS related stuff, ie avoiding to impose any constraints on the remaining service components
Let me respectfully conclude this WCS brief with the hope we can keep up a spirit of modularity across OGC standards.
regards, Peter Mike Botts wrote:
Ben et al.If you want to look at encoding large coverages in GML, I strongly suggest that you look at the SWE Common approach for defining the data structure and encoding and then packaging the data values into ascii, base64, or true binary blocks. This is available in the SWE Observation schema, but could be used for any Feature. Efficient packing and rapid parsing of large blocks of data are the resons we developed this approach. You can find some examples within the SWE Common encoding and examples section of the SensorML document (OGC 07-000). Thanks.Mike Botts
galeon archives: