Some random thoughts as I read through this discussion:
1. At the beginning of galeon, we wanted to explore whether one could use WCS
to deliver data (not pictures) to both GIS and FES users. One of the main
reasons is because WCS allows subsetting in coordinate space, while
opendap/netcdf can only use index space. So its important to acknowledge that
WCS can bo things that opendap/netcdf cant.
2. One needs CF to work in coordinate space. The code to implement
CF-coordinates is probably several thousand LOC. Casual users cant do this, so
push it to the server.
3. The bugaboo is the return format. Netcdf/CF is part of our community, but
not the GIS community. If we could get serious adoption from GIS clients, then
we could interoperate. We can push, but we dont have that much leverage ($$).
Real functionality in libcf might ease the burden on the non-java clients.
4. Theres really a lot more to be done in CF to create the data model and the
attribute encodings. We tend to mostly discuss how to encode, but the data
model is rarely discussed. The CF group tends to be rather conservative, and it
takes persistent effort to get new ideas accepted.
5. On the OGC side, they are heavy on the ISO data model and GML as an
encoding, but havent managed to keep the complexity from being overwhelming to
all but the most determined.
6. WCS core + extensions doesnt do much for interoperability. The best you can
hope for is that it allows different initiatives (we dont all have to agree)
and one comes to dominate and the others wither away (or stay useful only to
their constituency). If we pursue WCS 1.2, lets just accept this reality,
define our extensions, and then fight it out in the mindshare market. If we
want to deliver netcdf/CF files, opendap URLs, or CSML as the GetCoverage
payload, we can do that in "our" extension.
7. WMS (with possible enhancements) may be the best way currently to connect to
GIS and Google Earth clients. Perhaps floating point geotiffs for those who
want "data".
8. Roys EDC tools might very well obviate WCS for ESRI users. Not being an ESRI
user, I cant say for sure. Anyone have any opinions? Im not personally
impressed with ESRI's commitment to WCS and netcdf/CF, but id be happy to be
wrong. Perhaps we should pick some "second-tier" GIS clients who are hungrier
and get things to work there.
9. Next generation access protocols will allow asynch responses.
10. Next generation encoding formats will make streaming data easier for the
servers. (I have been experimenting with this in the TDS, and the "point subset
service" streams netcdf-3 files. That is, it can write on the fly without
staging the file. However, you need Java or the latest C libraries to read
these returnedfiles, since the "number of records" is not known in advance.
This trick only works because of the simplicity of the netcdf-3 format, and
very likely wont work for netcdf-4 etc).
11. So can we use WCS to deliver data? Id say the current answer is "yes, but
without clients, who cares?".
