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 [[email protected]]
Sent: 30 June 2015 16:58
To: Juckes, Martin (STFC,RAL,RALSP); [email protected]
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 [[email protected]] on behalf of
[email protected] [[email protected]]
Sent: 29 June 2015 13:31
To: [email protected]
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
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
