Hi Russ,
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.
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.)
- steve
==================================================
Russ Rew wrote:
> Jonathan Gregory wrote:
>
> > * only a subset of the CF community are users of GIS software, WMS
> > servers and MS Access. I'm not familiar with any of these, for
> > instance, and I expect I am typical of scientists working with
> > GCMs. It would make CF less easily usable, for those who are not,
> > to tie ourselves to particular software.
>
> Maybe it's time to break off GIS conventions into a separate
> orthogonal set of conventions for GIS users, which you would specify
> with something like
>
> :Conventions = "CF-1.0, GIS-x"
>
> to indicate that data conforms to CF version 1.0 conventions as well
> as GIS version x conventions. It might be beneficial to organize GIS
> conventions into multiple independent sets as well, such as WKT, EPSG,
> FGDC, etc., or nested levels encompassing more extensive GIS
> information for multiple uses. Decoupling GIS metadata from CF
> metadata would permit separate and perhaps more rapid development of
> the necessary conventions. Such decoupling would also permit the use
> of the GIS conventions independently or with other non-CF conventions.
>
> I think the subset of the netCDF community interested in accurate GIS
> metadata is large enough that a separate independent standard would be
> useful. There might even be GIS users who are interested enough to
> propose a draft set of conventions.
>
> As a disclaimer, I should state that
>
> * I'm not very familiar with the issues and the discussion that's
> already taken place in regards to expanding the CF conventions to
> provide more accurate and comprehensive GIS metadata.
>
> * It's not my intention to undermine the CF conventions, which I
> think are the best available netCDF conventions for many purposes,
> by suggesting that they be broken up into smaller orthogonal
> pieces.
>
> I'm just suggesting that CF and GIS conventions might evolve more
> easily if they were independent rather than tightly coupled.
>
> --Russ
>
> _____________________________________________________________________
>
> Russ Rew UCAR Unidata Program
> russ at unidata.ucar.edu http://www.unidata.ucar.edu/staff/russ
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
???,??,????`????,??,????`????,??,????`??????,??,???
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-6349
ph. (206) 526-6080, FAX (206) 526-6744
Received on Tue Feb 22 2005 - 15:28:21 GMT
