Re: [cf-pointobsconvention] Draft 2

Well, it's not that ridiculously straightforward :-(

CSML: The climate sciences *modelling* language, is the first (as far as we know) attempt to build a *model* of climate science features ("beyond" lines polygons etc, but "less than" grids) which are consistent with the geospatial communities ideas (especially as expressed in GML, but based on the underlying ISO and OGC standards) see ...

But, having done that, we still have to store the underlying binary data, and for that we prefer netCDF, and that does bring us back to initiatives like this. I don't think we can escape these thought processes :-) ... which will then feedback to iniatives like CSML and on a longer time scale, the harmonisation of the Unidata SDM, CSML and OGC fundamentals ...


On Thursday 11 October 2007 19:43:16 Ted Habermann wrote:

John forwarded this to me and I am glad to hear that you are interested.
I thought that I might provide a slightly different perspective to
explain why I think this is such a forward-looking idea.

The organization of this thought process seems to distinguish between
points, profiles, trajectories, and other types of spatial features with
an apparent goal of deciding on a file structure for each of these .
This makes this sound like a whole series of decisions need to be made
about a bunch of "different" data types (I could be completely wrong on
this). Luckily for us, the geospatial community has figured this one out
and all of them actually have agreed on a compact representation for all
of these types, and a bunch of others (multi-points, multi-lines, and
polygons, ...).

Seems to me that if this group recasts their framework to something more
like: how do we store spatial features (other than grids) and associated
attributes in a netCDF file, it allows you to jump forward by taking
advantage of years of work and success in the geospatial community.
After all, there are no point-shape files or line-shape files, or
polygon-shape files, there are only shape files. I think it would be
great if that were also true of netCDF. It also makes the connection
between netCDF and spatial databases ridiculously straight-forward.