NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.
Ethan et al, As part of a Met Office project to provide the foundation for a Service Orientated Architecture, I have produced a draft interface specification for a WCS which will be built on top of "Visual Weather" (a software package developed by a company called IBL), which will become the future Met Office forecaster workstation system - I mentioned this work briefly in an early posting to this mailing list.=20 As this is being developed by IBL, as an enhancement to their software, it will not be open source, but the interface specification is open, and the process of drafting this has thrown many of the issues that you have highlighted below. Therefore, so Jeremy (Tandy) and I thought it would be useful to share this draft document (attached) with the group. I should highlight that fact that this is a first draft to facilitate discussion with IBL, and not a finished specification; as such I know there are a number of issues with it and some significant gaps.=20 The interface specification is based on WCS 1.0, but I (like others) found that there were a number of areas, where I had to make design decision that potentially reduce interoperability. Where this was the case, I looked initially to follow the approach taken for a WMS that has already been produced for Visual Weather by IBL (to a Met Office specification), and them to the THREDDS WCS (which we have been doing some evaluation work on) and to the early ideas for the WCS 1.0+ spec. I should also warn you that the document effectively reproduces large chunks of the WCS 1.0 specification (albeit in a slightly different format) for clarity. I'd welcome any comments of this document, but I post it mainly in the hope of stimulating discussion through the provision of a strawman that is ripe for criticism! Regards, Bruce -- Bruce Wright IT Architect Met Office FitzRoy Road Exeter EX1 3PB United Kingdom Tel: +44 (0)1392 886481 Fax: 0870 9005050=20 E-mail: bruce.wright@xxxxxxxxxxxxxxxx http://www.metoffice.gov.uk
-----Original Message----- From: wcsplus-bounces@xxxxxxxxxxxxxxxx [mailto:wcsplus-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ethan Davis Sent: 20 November 2007 04:10 To: wcsplus@xxxxxxxxxxxxxxxx Subject: [wcsplus] 2D vs 3D domain and multiple parameters in range Hi all, Most of our gridded data is on a projection though a few are lat/lon (all use a spherical earth). Height is on isobaric pressure levels, some height above ground, and some on various layers between two vertical points (in meters, pressure, or sigma). In each "dataset", there are generally several parameters on each coordinate system (x, y, z, and t combination). Our current 1.0 implementation separates each parameter into a separate coverage and uses the range for Z. Though the spatialDomain/gml:RectifiedGrid contains x, y, and z which seems counter to having Z in the range. Any thoughts on that? Anyway, since one of the goals of WCS 1.0+ is to "allow multiple fields (with different units) in a coverage range", I'd like to get everyones thoughts on how to describe our data. It seems best to have x, y, and z in the CRS and the various parameters in the range. However, how to describe/identify the CRS doesn't strike me as very straight forward: 1. We can use any URI to identify a CRS but the 1.0 spec specifies "AUTO:4200*", "EPSG:*", "Image", and "Engineering" but not much else. 2. The OGC URNs for CRS aren't part of WCS 1.0 (and aren't too appealing in terms of their complexity for compound CRS that require parameters. 3. Am I missing another option in 1.0? 4. 1.1 seems to be going down the OGC URN route 5. Is there a better way? Also, most of our parameters are not vector fields, so the structure of the 1.0 RangeSet seems a bit ill fitting. The 1.1 Range seems better.=20 And the KVP encoding for GetCoverage range specifications seem much easier to implement. (I.e., you don't have to know the names of a particular coverages range parameters just to validate the HTTP KVP parameters.) What I would like to do: 1. Put X, Y, Z in the CRS but I'm not sure how to encode our non-standard (spherical earth, parameterized) projections and (non-height, layer) Z. 2. Parameters in a more 1.1 Range rather than 1.0 RangeSet 3. Native and response CRS as in 1. 4. Allowed request CRS as lat/lon and our non-standard Z 5. Would there be any advantage to also allowing "imageCRS" in the request CRS? Can we use HEIGHT, WIDTH, DEPTH or RESX, RESY, RESZ in that case to specify an array index stride even thought we only support "none" for interpolation? That's all I have for now. Thanks. Ethan
Attachment:
SOAF-VW_WCS_Specification.doc
Description: SOAF-VW_WCS_Specification.doc
wcsplus archives: