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