NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi John and Galeon folk, Excellent points. Just a couple of comments:
So its important to acknowledge that WCS can bo things that opendap/netcdf cant.
This is true, although this alone isn't a justification to spend huge effort designing and adopting a whole new protocol. Modifying existing protocols is another valid approach. Also, users don't type in WCS or OPeNDAP URLs manually - its done with a tool. Of course, this assumes we have CF-aware tools for every language, which we don't, so pushing this to the server is attractive.
11. So can we use WCS to deliver data? Id say the current answer is "yes, but without clients, who cares?".
Agreed - and I'm not convinced that the major GIS vendors are going to build good-quality clients in the foreseeable future. I've talked to a few GIS vendors informally and although they "buy" the WMS idea, they are much less convinced about WCS, WFS and so forth. They pay lip service to these standards to give the appearance of being "open" and "up with the game" but do not (yet) seem very interested in committing. This is probably partly due to conservatism and partly scepticism but also because they have their own proprietary data models and services that they want to keep pushing. Have others had different impressions of attitudes of GIS vendors? I think the solution to the client problem is to keep things simple and make it easy for client developers to do the right thing. Then we can make at least some progress. Complexity can come later following buy-in from users and software vendors. Jon On Thu, Sep 25, 2008 at 3:29 AM, John Caron <caron@xxxxxxxxxxxxxxxx> wrote:
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: