cf-pointobsconvention mailing list is no longer active. The list archives are made available for historical reasons.
Jonathan Gregory wrote:
Dear JohnYes, 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 xx xThey 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. :-)
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 oneof 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@xxxxxxxxxxxxxxxxFor list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/