Hi Phil, > Given the number and variety of OGC specifications, I'm not sure it's easy > to make a direct comparison. IMHO, some of the problems being addressed by > OGC specifications appear harder than CF, while others appear easier.
Fair point - I was thinking about WMS and simple-features-WFS really. The SWE suite is likely to be harder in this respect. > The question is whether or not we should be specifying an interface > standard for CF objects. I think this would be a good idea (it might be rather like GeoAPI and the GeoTools implementation) but it would probably be quite a lot of work and would need to translate well across languages. But I agree that such a thing would be useful to me as a tool developer. There are synergies with data models such as CSML here too. Perhaps the Unidata people have comments here? Cheers, Jon On Mon, May 12, 2008 at 10:47 AM, Philip Bentley <[EMAIL PROTECTED]> wrote: > > Hi Jon, > > > > Hi Phil, > > I agree that the solutions aren't easy and will require more resources > (by the way, why can't the CF community start applying for more > resources? Surely the demand is there?) > > Compliance checking in the CF world is likely to be much harder than > in the OGC world. The OGC compliance checks simply check syntactic > compliance, whereas in CF we have much more semantic information. A > NetCDF file can comply syntactically with CF very easily but be > semantically nonsense. (I think I've just repeated what you said in > different words...) > > Given the number and variety of OGC specifications, I'm not sure it's easy > to make a direct comparison. IMHO, some of the problems being addressed by > OGC specifications appear harder than CF, while others appear easier. > > Just to see if I've understood correctly - are you proposing that, > instead of testing that a CF file is syntactically correct, we develop > a suite of "test cases" (data + operations) that vendors can use to > test their software? E.g. we provide a data file and an operation > (e.g. "calculate the zonal mean") then vendor's software can be tested > to see if it gets the right answer? > > Yes, that's pretty much it. For example, if we take the new grid mapping > attributes defined at CF 1.2, at present a client application would need to > know about, and read, several CF attributes in order to 'understand' the > coordinate reference system used by a particular netCDF dataset. These > attributes include, e.g. grid_mapping, grid_mapping_name, semi_major_axis, > inverse_flattening, latitude_of_projection_origin, and so on. These then > have to be examined/interpreted to by each application to see if, > collectively, they are self-consistent. > > With the interface approach we would define CF-standard operations like: > > set/getFigureOfEarth(...) > set/getCoordinateReferenceSystem(...) > set/getGeodeticDatum(...) > etc > > Implementations of these operations would ensure that only valid > figure-of-earth / datum / CRS objects were written to or read from a netCDF > file, thus achieving the required compliance. Client applications need then > have no special knowledge of how these objects are actually realised as > attributes in a netCDF file. > > Of course there's nothing new in this suggestion. Presumably it's being > used in any number of bespoke applications and frameworks (e.g. netCDF-J, > libCF). The question is whether or not we should be specifying an interface > standard for CF objects. > > Cheers, > Phil > > > > > On Fri, May 9, 2008 at 12:27 PM, Philip Bentley > <[EMAIL PROTECTED]> wrote: > > > > Hi Jon, > > > > Unfortunately I don't think there are easy answers to the issues you > > describe. My experience from the GIS world is that commercial software > > vendors advertise compliance to particular versions of standards and that > > this compliance is ratified against some kind of reference implementation > > (test software and/or data) maintained by the appropriate standards body. > > This certainly seems to be the way that the Open Geospatial Consortium > > approaches this conformance requirement. And this seems to be the approach > > suggested in Ethan's and John's recent responses, which I would happily > > echo. > > > > However, the OGC and similar bodies have considerably more resources to > > bring to bear to the problem, resources the CF community doesn't appear to > > have at present. So do we adopt a similar methodology, but on a manageable > > scale? Or should we consider moving CF development and governance under > the > > auspices of a body - like OGC (if they'd have us :-) - with deeper > pockets? > > > > It occurs to me, however, that part of the problem may be due to the fact > > that CF is primarily focussed on defining an information model, not a > > programming interface. And while software practitioners have plenty of > > experience of developing solutions that conform to well-defined interfaces > > (netCDF and OGC's WMS, WFS & WCS being fine examples), I'd contend that > they > > have much less experience of developing solutions that test whether or not > a > > particular dataset conforms to a particular information model. Or that a > > conforming dataset makes any sense in a given end-user context - which > seems > > to be what we're asking of CF-compliant software. Personally, I don't > > believe that's a tractable problem. > > > > Perhaps this interface-based approach is what CMOR and libCF are trying to > > do. Unfortunately I have little experience of either of these initiatives > so > > I'll leave it to others to comment on these. But if we really want to get > a > > handle on software compliance issues then, IMHO, I believe we need to go > > down the defined interface route. And the netCDF API itself should give us > a > > good steer on how to go about this. > > > > Cheers, > > Phil > > > > > > > > > > > And I could read this file today using, say, ncdump and ncview. Which > > > clearly doesn't tell us much. > > > > This is a really important point. It would be very difficult, in the > > general case, to ascertain whether a certain piece of software > > actually interprets a certain CF attribute correctly. Conversely it > > is perhaps unreasonable to expect a piece of software to implement > > correctly every feature of a certain CF version. > > > > What a tool user really wants to know (I think) is, for a given NetCDF > > file, which attributes in the file are correctly interpreted by the > > tool. I can't think of a neat way to do this - perhaps tool > > developers could publish a list of attributes that they claim to be > > able to interpret for each version of the tool they produce? A given > > tool might then implement 100% of CF1.0 but 50% of CF1.2 for example. > > Then the CF community could maintain a list of tools that users could > > go to to find out which tools might be most suited to their purpose. > > > > An add-on to the CF compliance checker could be created that, having > > scanned a file for CF attributes, produces a list that says "Tool X > > understands all of the attributes in this file, but Tool Y only > > understands 7 out of 9". > > > > All this requires effort of course, but I think it's useful to > > consider what we really mean when we call for "CF compliance". How > > can we help users to judge which tools they should use and how can we > > help data providers to ensure that their data can be interpreted by a > > wide community? > > > > Jon > > > > > > > > > > > -- -------------------------------------------------------------- Dr Jon Blower Tel: +44 118 378 5213 (direct line) Technical Director Tel: +44 118 378 8741 (ESSC) Reading e-Science Centre Fax: +44 118 378 6413 ESSC Email: [EMAIL PROTECTED] University of Reading 3 Earley Gate Reading RG6 6AL, UK -------------------------------------------------------------- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
