Hi Folks
... and finally a short response :-)
I think the key point is that CF can never be all-encompassing, as CF becomes
more successful, it will have to interoperate with more and more communities.
However, the GIS community is pretty important. We already have the climate
impact community asking for climate data in GIS formats, and that's why we
have a significant effort on extending GML for metocean data (see
http://ndg.nerc.ac.uk/csml). We've also invited an ESRI representative to the
GO-ESSP meeting in June ...
I think the approach of embedding GIS info in CF compliant netcdf files is the
way to go for now. A long term approach would of course be to move to GML
compliance within CF - but we can't do that because GML can't cope with
existing MetOcean data coordinate systems. But it is the obvious track that
we should proceed down (indeed, we're working on the GML extension issue as
well). At some time in the future GML will contain all the projection and
coordinate information we need, and then we can use it inside our CF files.
Which makes me wonder why we would use WKT instead of the XML version? While
we can use GDAL, it's generally much easier to parse this stuff in XML (which
is why XML exists). Why not embed the XML?
And from an epicycle point of view, we should then come up with a CF compliant
way of pointing to arbitrary external XML descriptions ... not just this one.
Bryan
On Wednesday 23 February 2005 23:31, Russ Rew wrote:
> 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/msg
>02107.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.h
>tm
> 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/msg
>02111.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
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Bryan Lawrence, Head NCAS/British Atmospheric Data Centre
Web: badc.nerc.ac.uk Phone: +44 1235 445012
CCLRC: Rutherford Appleton Laboratory, Chilton, Didcot, OX11 0QX
Received on Thu Feb 24 2005 - 04:19:38 GMT
