Re: [cf-pointobsconvention] Draft 2

• To: cf-pointobsconvention@xxxxxxxxxxxxxxxx
• Subject: Re: [cf-pointobsconvention] Draft 2
• From: Jonathan Gregory <j.m.gregory@xxxxxxxxxxxxx>
• Date: Mon, 24 Sep 2007 10:21:28 +0100

Dear John

Yes, this is not the same as "irregularly spaced grids". I was trying to emphasize the kinds of data i thought this would cover, including "station" "trajectory" "profile" (etc). Perhaps "ungridded" is better than "point" (others have an opinion?).

"Ungridded" is a more neutral and general term, I think.

I've been calling the case of "size of one dimension may vary as a function of index along another dimension" as "ragged arrays" (versus the usual "rectangular arrays").

I understood "ragged" arrays to means one where some rows didn't have the
full dimension, but all start at 0 e.g.

  x x x x
  x x x
  x x x x
  x x x x x
  x x

These arrays are more sparse that that. It might well be that the rows have
few columns in common and they very likely do not all start at 0:

  x   x       x   x
    x         x   x
        x x x   x

They could have no columns in common at all. In that case it is not obviously
an "array", but it can still be regarded as one, and your scheme is effectively
a compression to eliminate the unused space.

Im actually proposing a new "table" data type with "index joins" as a way to think about these types of data. This does look like your example above (though you need to keep the record dimension as the outer dimension):

   float latitude(station);

   double times(record);
   int station_index(record);
     station_index:compress="station";
   float humidity(record,pressure);
     humidity:coordinates="station_index";

   float pressure(pressure);

OK. So the pseudo-SQL description is just a way to think about it. I agree, it
it can be seen like that. A join can construct one of these extremely sparse
arrays. I quite like the CDL itself, as I said. That's the truth of what is
going on, and there are various abstract ways to understand it. :-)

It is a discovery attribute and also used by clients to know how to interpret the connectivity of the data. Without it, one could not (for example) distinguish a collection of earthquake data from a trajectory. Both look like:

variables;
 float lon(obs);
 float lat(obs);
 float z(obs);
 double time(obs);

 float dataVar(obs);
  dataVar:coordinates = ?lon lat z time?;

Is it possible you could store such a description in one
> of the existing global attributes whose contents aren't standardised by CF?

Yes, I agree that kind of info is useful for discovery. People are thinking
about discovery metadata in other contexts, aren't they? Perhaps this issue
has already been addressed somewhere else.

Best wishes

Jonathan

• Follow-Ups:
  • Re: [cf-pointobsconvention] Draft 2
    • From: John Caron