Hi Steve,
> All that you have said is true and nicely summarized in your concluding
> word, "CF and GIS conventions might evolve more easily if they were
> independent rather than tightly coupled". But isn't this approach
> perilous for interoperability? (ah, the epic battle to support the forces
> of convergence over the forces of divergence ...) Moving to greater
> independence between the encoding of model grids and GIS data is not a
> desirable thing if it means that GIS clients are not able to access model
> grids and scientific anal&viz packages are not able to access GIS data
> without each application requiring two separate software development
> tracks.
I think you've identified the main problem with the approach I
suggested.
I agree with your concerns about interoperability, and think that it
would be ideal to have one all-encompassing set of CF conventions that
netCDF and GIS clients and servers could use. But this also puts a
fairly heavy burden on the CF authors (Brian Eaton, Jonathan Gregory,
Bob Drach, Karl Taylor, and Steve Hankin(!)), which might be eased by
parallel development of GIS extensions to CF.
There is also a need for GIS servers to make their data available in
netCDF form. In the previous posting, I forwarded a reply from Steve
Kopp of ESRI suggesting use of OGC "Well Known Text":
http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/doc-files/WKT.html
Independently of that, Benno Blumenthal proposed, on the OpenDAP
mailing list last August, using the same OGC WKT for coordinate
systems and projections:
http://www.unidata.ucar.edu/content/support/help/MailArchives/dods-tech/msg02107.html
And Ben Domenico and other THREDDS collaborators have recently
proposed adding netCDF to the current list of OGC "blessed" binary
encodings for Web Coverage Servers, using a closely-related XML
representation for the GIS information:
http://www.unidata.ucar.edu/projects/THREDDS/BenStuff/Documents/WCSnetCDF.htm
http://www.unidata.ucar.edu/projects/THREDDS/OGC/WCS-THREDDS%20Gateway.htm
> The direction that Jonathan's email was leading seemed promising: how to
> augment GIS codes (which require external tables) with extra content in
> order to make them self-describing. (but not easy in general!). Another
> approach entirely is through client libraries based upon a rich data model
> -- i.e. that Unidata (or others) would provide multi-language APIs so that
> applications need not be aware of the specific details of the netCDF
> conventions. These approaches might be blended -- e.g. could we envision
> well-supported libraries in multiple languages (packaged with the netCDF
> client code) that could return CF-style coordinates given inputs of GIS
> codes and parameters? (I assume we all agree that Java-only solution
> would not be sufficient.)
The development of such client libraries seems ambitious and hence a
candidate for a long-term solution. A Java-only solution might be
adequate for servers, but not clients. In the meantime, I would like
to second Steve Kopp's and Benno Blumenthal's proposals to consider
the addition of the OpenGIS Well Known Text string as a possible
short-term solution for CF, along with an attribute convention Benno
proposed for connecting the coordinate systems defined by WKT and the
netCDF coordinate dimensions:
http://www.unidata.ucar.edu/content/support/help/MailArchives/dods-tech/msg02111.html
There is library support for the OGC WKT string encoding, providing
ways to convert it to and from other representations, in Frank
Warmerdam's widely used and freely available GDAL library:
http://www.remotesensing.org/gdal/
--Russ
Received on Wed Feb 23 2005 - 16:31:58 GMT
