NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
A few notes below: Jon Blower 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 nosubsampling either.
because the data volumes can be so large, we have found that visualization users want subsampling.
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 replicatesOPeNDAP functionality).
I assume by curvilinear, you mean ones with 2D lat/lon, such as swath data, not the simpler case of projection coordinates.
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. thatthis would take us into the realm of WMS.)
Since youve actually done WMS, i'd probably trust you more on this. 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.
This is quite an important question. If WCS1.2 "core plus extensions" has the right division of functionality, then the metocean community could define the extensions it needs for 4D data, asynchronous delivery, more complex CRS than rectified grids, opendap URLS, etc. The people actively developing servers _and_ clients could rapidly iterate to the point of having something that works.
Can anyone who knows WCS 1.2 summarize 1) whats in the core, and 2) what is allowed in the extensions?
galeon archives: