Hello Mark,
If the two end points can be specified with bounds within the existing convention, it might be simpler to use that. Can you explain to me how this is done? The only reference to bounds which I could find in the convention was in connection with cell boundaries.
The flow direction does need to be defined .. I suppose that would involve a clarification of the standard_name ocean_volume_transport_across_line. As you say, this should not be too complicated once we have a definition of the line to refer to.
The approach I was thinking of could easily accommodate multiple points on a line, though I don't have a use for it at present. e.g.
float mfo(ntransect):
....
coordinates: "passage lon lat"
float lat(ntransect):
....
transect: lat_trans
float lon(ntransect):
....
transect: lon_trans
float lat_trans(ntransect,npt):
float lon_trans(ntransect,npt):
Where "ntransect" is the number of transects and npt is the number of points use to define each transect (>=2).
regards,
Martin
________________________________________
From: Hedley, Mark [mark.hedley at metoffice.gov.uk]
Sent: 30 June 2015 16:58
To: Juckes, Martin (STFC,RAL,RALSP); cf-metadata at cgd.ucar.edu
Subject: RE: [CF-metadata] Specifying latitude and longitude of transects and regions
Hello Martin et al
this sounds an awful lot like an extensive feature definition to me.
such definitions are widely supported in spatial data sets and software.
It would be very useful to be able to define these in CF. I would not limit this (in principal) to defining the start and end of a line, there seems to me little added complexity in defining a line of n points rather than a line of 2 points. This is already done with bounds
There is lots of prior art, in ISO, GML, OGC so we won't need to invent very much.
In the end these are just coordinate collections, we can use lots of what is already in CF to define them.
If these are lines which flow is defined through then we'll also need a direction of flow to be defined, does this sound correct? There's also prior art for this.
This sounds a really useful capability extension to me. I think the extensions you are looking for could be delivered quite neatly.
I expect there will be a few ways to approach encoding this information. I think it might be worth sketching up some options and how they'd look, then discussing their strengths and weaknesses. I'd be happy to contribute to such an activity, if that would be useful.
mark
________________________________________
From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of martin.juckes at stfc.ac.uk [martin.juckes at stfc.ac.uk]
Sent: 29 June 2015 13:31
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] Specifying latitude and longitude of transects and regions
Hello All,
There are some variables in the CMIP5 archive which lack explicit latitude and longitude information, such as mfo (standard name sea_water_transport_across_line) and msftzzzba (ocean_y_overturning_mass_streamfunction_due_to_bolus_advection). The first is a mass flux across a transect and the second is a zonally averaged stream function, averaged across an ocean basin.
For transects, the mfo variable is encoded with an index dimension and a coordinate "passage" which labels transects by the name of the passage they cross (e.g. fram_strait). The information about precisely which part of the Fram Strait is used is in a document referred to from the MIP tables. It would be nice to have a means of encoding the end points of the transect in the CF metadata. I looked into using the "bounds" attribute, but that is defined to represent cell boundaries, so an extension to the convention is, I think, needed. It makes sense to follow the pattern used to represent cell boundaries. I propose defining a new attribute "transect" which, like the "bounds" attribute, can be attached to coordinate variables and takes the name of another variable as its value. The named variable should contain the end points of the transect.
The same approach could be used for the streamfunction .. which is a mean across an east-west transect (this approach would lead to a specifcation of the east and west endpoints of each basin at each latitude -- but I'm not sure that it would be feasible to collect that much detail in the CMIP data files).
Is there a cleaner way of encoding transect and basin coordinates?
regards,
Martin
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Tue Jun 30 2015 - 14:32:13 BST
