Re: [cf-pointobsconvention] Draft 2

• To: cf-pointobsconvention@xxxxxxxxxxxxxxxx
• Subject: Re: [cf-pointobsconvention] Draft 2
• From: John Caron <caron@xxxxxxxxxxxxxxxx>
• Date: Mon, 24 Sep 2007 11:56:34 -0600

Jonathan Gregory wrote:

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.

Im a bit worried thats its too general. For example, another data type we are interested in is 
"radial" (eg radar). Weve been reserving "grid" to mean "grids in cartesian 
coordinates".

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

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.

yes, i see what you mean.

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. :-)

yes

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.

Im not sure. I'd like to encourage a "discovery metadata" working group to get 
started.

Best wishes

Jonathan
_______________________________________________
cf-pointobsconvention mailing list
cf-pointobsconvention@xxxxxxxxxxxxxxxx

For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/

• References:
  • Re: [cf-pointobsconvention] Draft 2
    • From: Jonathan Gregory