Dear CF community, I would like to add some more considerations to Mark Hedley and Jim Biard's detailed and well founded technical comments over the debate about some fundamental concepts of abstract data models for geospatial interoperability. I apologise if I am teaching anyone to suck eggs etc, but it does help to get my thoughts in order.
The UK Met Office, and other national met services and institutions, such as NCAR, NWS, BoM, DWD and Météo-France, have put significant efforts over the last five years, at the level of the equivalent of several full time staff per institution per year to make meteorological data and services, for both weather forecasting and climate prediction, more readily accessible to a much wider, and richer, world of geospatial services, both now and for decades into the future. Significant effort has gone into making meteorological and aviation data have a common, shared conceptual model to ensure interoperability well into the future. A simple version of such a model has existed in peoples' heads for decades, but many modern software tools (which many meteorologists tend not to use yet) are predicated on a formal version of a conceptual model, whether expressed in UML, XML or other languages. Discovery and use of data and services are also predicated on search engines and similar mechanisms and these are increasingly relying on underpinning conceptual models and their semantics to ensure good results. Such formal models tend to have more layers of abstraction than naïve users expect. This gives 'loose coupling' enabling flexible software, and also tight semantics, giving clear meaning. The models also tend to be richer than expected because they are encompassing the full domain, of which only a subset may be implemented at any one time. Providing the conceptual components are stable, this gives some measure of future proofing too. Processing such conceptual models is not particularly resource intensive, as, for example, most modern phones contain such a software kernel to handle internet activities. To summarise, I do not see why a conceptual model should not have two concepts that are different, and modular, even if implementations of current software conflate the two for reasons of history or efficiency. In the future, software implementers will still have the opportunity to conflate concepts for the sake of efficiency. This is a well recognised pattern in IT, e.g. 3rd Normal Form and denormalised databases, XML and lots of tools, shared application memory, etc. Another IT pattern, that I would like to break from, is that of embedding backward compatibility for too long, distorting future software and imposing undue costs of maintenance and complexity. Chris -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mark Hedley Sent: Tuesday, April 15, 2014 4:51 PM Subject: Re: [CF Metadata] #107: CF Data Model 1.7 This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at http://kitt.llnl.gov/trac/. #107: CF Data Model 1.7 -----------------------------+------------------------------ Reporter: markh | Owner: cf-conventions@… Type: task | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+------------------------------ \ \ \ \ \ \ Comment (by markh): Replying to [comment:79 jonathan]: Hello Jonathan > Both `grid_mapping` and `formula_terms` can be described logically by the > [http://kitt.llnl.gov/trac/ticket/107?replyto=55#comment:55 text which > David posted]. For instance, I can see that this can be done, the important question for me is should it be done? Where are the benefits and where are the costs? I do not perceive the benefits of this conflation to form a new `geolocation` type, based on the comments to date. This conflation is quite a jump from the current CF conventions terminology, which concerns me; I think it is difficult to explain. > What is to be gained in clarity or simplicity by regarding these two things > as distinct concepts? We don't talk about transforms or coordinate > reference systems because these terms have technical and sometimes > restrictive meanings, and therefore may make the description less clear. A particular benefit I see in having two separate concepts in the CF data model is interoperability with other domains and concepts. If a concept in the CF data model cleanly and clearly relates to a concept in another domain then this is a big supporting factor for interoperability. I think this is the case here: the georeferencing capability provided by a coordinate reference system type of thing in CF is very closely aligned to the ISO19111 definition of a coordinate reference system. This brings huge benefits in providing interoperability with other ISO aware communities, such as the OGC, as highlighted by [comment:80 edavis]. I think this is the approach Stefano has taken with the OGC to date. The documents he has written link grid_mapping variables to OGC CRS instances. The derivation of coordinate values, perhaps for georeferencing purposes, based on bespoke defined algorithms and reference data sets is a much more specialised field, which is not widely used in the ISO and OGC communities (for example). Conflating the well known georeferencing function of coordinate reference systems with these derived coordinate functionality in a single data model type is making it very hard for that type to be understood and used effectively by other communities. It also makes it much harder for CF to adopt useful building blocks for other communities, as the interfaces are all in different places. So, the cost of the approach of conflating these concepts is it isolates the CF community from other communities, just when we and they stand to benefit so much from better interoperability. The benefit has to significantly outweigh this cost, and I am afraid I cannot see this. With this in mind I strongly favour the separation of these concepts within the data model. Whilst they can be logically conflated, I think the cost is prohibitive and the benefit minimal. all the best mark \ \ \ -- Ticket URL: <http://kitt.llnl.gov/trac/ticket/107#comment:82> CF Metadata <http://cf-convention.github.io/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message. _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
