NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Jon, Thanks for spawning all this valuable conversation. This is about as productive as I've seen the GALEON group. In answer to your one question about core vs. extensions, my thought is that distinction is not as important as it might seem. Anyone who wants to access CF-netCDF data via WCS will have to do so via an extension to the core. I believe Stefano has done an excellent job of drafting that extension and we have some good suggestions now for adding a "delta" to the extension which could tie in OPeNDAP as an alternative for those who are used to that protocol. In fact, unless the WCS 1.2 core definition has changed recently, WCS will require every client to use an extension because none of the encoding formats are part of the core. So even geoTIFF encoding will be defined as an extension. So I think the top priority for us now is to come up with an augmented version of Stefano's draft and submit that formally to the WCS 1.2 Standard Working Group. I hope we can do so in advance of the next OGC Technical Committee meeting in December. To my way of thinking, after the CF-netCDF WCS extension standard, the next important step on the critical path is to augment CF conventions for datasets other than grids. But that is a topic for another email thread and perhaps another email list too. Thanks again. -- Ben On Tue, Sep 30, 2008 at 5:43 AM, Jon Blower <jdb@xxxxxxxxxxxxxxxxxxxx>wrote:
Hi Ben et al., Yes, I take your point here. Thanks also to John C for a very instructive post. I've learned a lot from this discussion and I'm aware that I could keep bugging everyone ad infinitum, so I'm going to have a go at summarizing some issues in a short essay (for my own benefit as much as anything else). Please let me know if I've got the wrong end of the stick at any point. Here goes (starting at the very beginning): The metocean community is standardizing around CF-NetCDF as a self-describing data format. Within the community such data are typically shared either as flat files (through HTTP/FTP etc) or through OPeNDAP servers, which provide aggregation and subsetting capabilities. A large amount of tooling has already been generated around this approach. The WCS specification has the potential to bring new capabilities, primarily: (1) the sharing of data and metadata with external communities who are familiar with WCS but not with OPeNDAP etc; and (2) the ability for all users to access data subsets based upon coordinate values rather than array indices. Other potential future benefits of WCS include the ability to use GetCoverage to access a _reference_ to a data (sub)set, rather than a file. This reference could be specified as an OPeNDAP URL or as a URL to a pre-extracted file on an HTTP server. This allows for "asynchronous" access in the case of large, time-consuming data extraction jobs (see the "WCSplus" effort), and also allows the reference to be passed to a downstream service in a workflow scenario. Data consumers that might wish to access a WCS server can be roughly divided into two categories. The first category of user (typically a metocean scientist) requires data to be transmitted without loss of information: i.e. no regridding or interpolation and probably no subsampling either. Such a user would need to specify data subsets either in the native CRS of the data (which might be difficult for curvilinear coordinate systems) or in index space (which replicates OPeNDAP functionality). These access patterns may require a high degree of sophistication on the part of the user and/or the client tools in question. Data would be delivered either as a CF-NetCDF file or an OPeNDAP URL. The second category of user requires a simple and familiar means of accessing data but does not care if the data are manipulated behind the scenes. Such users can be helped by providing access to metocean data in familiar projections such as lat-lon, and in familiar file formats such as GeoTIFF (for 2D slices only). (I think it would be valuable to expand the scope to include requests in other common CRSs, particularly polar projections - I tend to disagree with John C. that this would take us into the realm of WMS.) If these users require 3- or 4-D data subsets (which I anticipate is a minority of this class of users) they will have to download data in CF-NetCDF - some GIS tools are building in support for CF-NetCDF but it is probably unlikely that they will be able to interpret the CF conventions in their entirety for the foreseeable future. Work still remains to be done to pin down the core use cases in order to guide the community's limited effort and resources to the benefit of the maximum number of users. (It seems to me that aiming initially at "non-scientific" users will give a better return on investment than aiming at the scientists because we can offer more new capability - for the scientists we are essentially offering a new way of doing things they can do already, plus or minus a few deltas. This is only my view though and I do appreciate there is value in targeting both categories of user.) One question to finish - do the two (artificial) categories of user above map onto the WCS1.2 "core plus extensions" concept? I could imagine that the "non expert" users might use "core" WCS whereas the experts would use the extensions, but I'm almost completely ignorant of WCS1.2. Cheers, Jon
galeon archives: