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
