Re: [cf-pointobsconvention] Draft 2

Don et al.,

My references to shape files seems to have confused rather than clarified. Hate it when that happens.

The point that I was trying to make is that shapefiles (and spatial databases) store generic spatial objects rather than points or lines or polygons. This is the critical concept. These objects are really structures that include integers that give byte-order and type, an integer that gives number of points, and an array of pairs that give latitude and longitude (details are described in the results of a google search for well known binary).

I was suggesting that this group might be able to build on that experience by dealing with spatial representations in the same way. I thought that this was consistent with what John was proposing in the parent table discussion. The netCDF file would include a blob of some number of features in the "header" that would be read and assigned ids (or they could include ids). The attribute data would be later in the file in what I think would be a standard netCDF array. That array would include an id that points to the spatial objects in the blob. This mechanism would be transparent to the users and would allow exactly the same file format to be used regardless of the details of the spatial objects. In fact, it would also allow multiple types of spatial objects to be in the same file.

That is what I thought of when I read "parent table". Sorry for the confusion.

BTW, I'm not sure what the binary representation of spatial objects in shape files is, but, whatever it is, I would suggest using WKB instead.

Also, I agree with Don on the importance of semantic standards on top of whatever syntax standard you are using. My reference was to shapefile syntax, not semantics.

Ted



Don Murray wrote:
Ted/John

John Caron wrote:

My intention is to make a single convention that would handle points,
stations, profiles, trajectories, and even other topologies not yet
thought of. So I think we are on the same page.

Thanks for mentioning shapefiles, I will review that format to see
what lessons are to be learned there.

The benefit of this exercise is to set standards for attributes
of the data and document them so they can be self describing.
I see this as a major downside to the shapefiles that I've dealt
with.  For example, there is no standard name  for latitude and
that can be listed  as an attribute  LAT,LA,CLAT, etc.

It would be nice if the GIS community could have the kind of
conventions for shapefiles that we have for netCDF.  In the
end, they are all just netCDF files, but the conventions help
define the structure and interoperability.

Don
*************************************************************
Don Murray                               UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************