NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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 forInteresting; 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.
galeon archives: