NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Gerry, Jon, Steve, Ben & Co, > > Even in some of our rather broad groups, now, (SensorML/SWE), although > there's broad agreement that there's benefit in ocean observations, the key > focus remains based on the satellite (imagery) origins of SensorML. >>> David Arctur of the OGC suggested that we submit the CF-netCDF directly >>> as an OGC standard. As I understood his suggestion, the general idea would >>> be that CF and netCDF would be for binary data what GML and XML is for text >>> data. About a year ago I heard Mike Botts talk about SensorML as being developed for remote sensing data. I was very surprised, because I thought SensorML was for "small" data sets, delivered via XML. But he was talking about using XML for the "light" metadata, with references to "out of band" binary files for the "heavy" data. A year later, as part of my detail to the NOAA IOOS Office, I'm working with model providers to develop NcML that makes their existing NetCDF files become CF-compliant, by adding XML to change or add the "light" metadata, and pointing to existing NetCDF files for the "heavy" data. So in my mind, both SensorML & NcML and OpenDAP & GIS worlds seem closer than I originally thought, and I'm excited about this new conversation with OGC also. -Rich On Thu, Sep 25, 2008 at 8:37 AM, Gerry Creager <gerry.creager@xxxxxxxx> wrote: > Jon Blower wrote: >> 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. > > The protocol, though, isn't completely new. It is, however, in > transition. I think the point, though, is in John C.'s statement: The > WCS standard allows things that NetCDF doesn't, and vice versa. Pushing > this to the server *does* make sense. > >>> 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? > > Adoption in the course of a software development and acceptance process > takes time, and there is, I'm sure, a bit of the old closed-source > culture to contend with. However, the evolving nature of the WCS > standard is such that it may well take time for commercial vendors to > incorporate something. I expect FOSS to develop a decent reference > implementation and release it first, although I'm not going to guess who. > > Note that the various OWS efforts have yielded commercially undertaken > WCS servers... and clients... and that in the US, WCS is being adopted > by the National Geospatial Agency. > >> 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. > > Always a good view. > > gerry >> 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 mailing list >>> galeon@xxxxxxxxxxxxxxxx >>> For list information, to unsubscribe, visit: >>> http://www.unidata.ucar.edu/mailing_lists/ >>> >> >> >> > > -- > Gerry Creager -- gerry.creager@xxxxxxxx > Texas Mesonet -- AATLT, Texas A&M University > Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.862.3983 > Office: 1700 Research Parkway Ste 160, TAMU, College Station, TX 77843 > _______________________________________________ > galeon mailing list > galeon@xxxxxxxxxxxxxxxx > For list information, to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ > -- Dr. Richard P. Signell (508) 457-2229 USGS, 384 Woods Hole Rd. Woods Hole, MA 02543-1598
galeon archives: