Hi Peter et al,
I am glad that Peter mentioned "time-only" coverage in this discussion. I suggested
looking at "profile" coverage in the WCS SWG sometime ago and resulted in some
discussions. I remember that John C. and Ethan were also involved at some point. But no result
has been reached. Profile coverage seems difficult to be served in current WCS. Since most, if
not all, experts in the metaocean community are very familiar with profile data. I'll try to see
if we will be able to judge if profile coverage is appropriate in WCS.
First, I would like to see if the following is a reasonable use case (numerical
data values are just arbitrary). Please disregard the rest of the mail if you
think this is not or rare use case.
A user requests a moisture profile from height 0 to 20 km over the region of
longitude from 0 to 30 degrees and latitude from 0 to 20 degrees, on day
2008-10-01. This assumes that there is a data provider provides moisture data
in the region.
If the above is a common use case, then let's consider if WCS can meet such a
request.
1. What is a profile?
There are many possible profiles but the one I refer here is a 2D data array, with one dimension being height (or depth, pressure) and the other being a near horizontal track on (or near) the earth surface.
Note: Profiles having more than 2 Ds have the same issue. I just use 2D for simplicity.
2. Why WCS rather than WFS?
WCS is for "Grid" coverage. The 2D profile mentioned in (1) is a 2D grid and
seems more suitable in WCS than in WFS which is for feature type (usually
vector/polygon/point data).
3. The problem to serve profile data in WCS
3a) it's possible, and actually very straightforward, to serve profile data in
WCS by declare the profile's dimensions being some kind of engineering CRS
dimensions and then allow user to request data based on these two dimensions.
The most simple case is just using the array indices.
3b) however, the WCS requires a spatial BBOX that include at least 2D near
horizontal dimensions. The problem is that the profile does not have 2D
horizontal dimensions. It has only 1D in horizontal surface, i.e., the track
of the profile on a 2D surface.
3) simply remove the requirement of two near horizontal dimension in WCS BBOX may not
work in actual use case. For example, a user may want to have "a temperature
profile over North America". In this case, the user needs a 2D horizontal BBOX to
define the extents of the profile's geographical region, BUT he/she does not expect the
coverage to have data points in the horizontal 2D BBOX except for points in the profile
track. WCS, on the other hand, expects that the two horizontal dimensions will define
many grid points on the surface and there must be data values for all the grid points.
I guess that in Peter's time-only use case, people don't not need to define data's geographical region, i.e., the user will get data for the defined time period wherever the geographical position. This is usually the case when a WCS serves data for a fixed geographical region, such as profiles for one or more ground station. Geographical position may also included in time value for satellite observation. In such cases, remove WCS's requirement on the 2D near horizontal BBOX may make the WCS work.
Regards,
Wenli
----- Original Message -----
From: Peter Baumann <p.baumann@xxxxxxxxxxxxxxxxxxxx>
Date: Thursday, October 2, 2008 3:29 am
Subject: Re: [galeon] WCS CF-netCDF profile document
Hi all,
this discussion is very valuable to the WCS group, it certainly
will
impact our discussions.
John Caron wrote:
There is still a hope that core + say, geotiff would be a good LCD (lowest
common denominator) to strive for
Interesting; actually one argument for us to avoid any format encoding
in the core was that other communities should not be bothered with
formats they are not interested in. Good to know that you folks like
Geotiff :-)
Still, however, there is further communities. In future WCS is intended
to cover all the spatiotemporal dimensions equally, which includes any
subset of the xyzt axes. In particular: "time-only" coverages will be
supported, particularly having in mind the SWE community. (On a side
note, there will be a dedicated harmonization meeting at the next TC
meeting in Valencia where SWE's O&M and the WCS coverage model will talk
to each other, among others.)
Now environmental sensoring people might implement a WCS supporting 1-D
time series which never will offer 2-D coverages; IMHO we should not
force them into supporting Geotiff. Notably this is not only about
plugging in open-source libtiff. It concerns coordinate conversion,
interpolation, etc - in short: a hell of a lot of work, in their case
just for nothing.
Bottom line, we could not find any format which all communities
uniformly are interested in, so we factored it out.
