⇐ ⇒

[CF-metadata] Specifying latitude and longitude of transects and regions

From: Hedley, Mark <mark.hedley>
Date: Fri, 17 Jul 2015 15:21:10 +0000

Hello Karl

I thought that Martin had presented a use case from CMIP5 which was expected to be repeated in CMIP6

Thus, I thought it likely that specifying data variables related to transects and regions would be done quite widely in CMIP6

You seem to think this is not the case, please may you elaborate a little on why for us?

thank you
mark

________________________________________
From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of Karl Taylor [taylor13 at llnl.gov]
Sent: 08 July 2015 01:26
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Specifying latitude and longitude of transects and regions

Hi Martin, Mark, and all,

I can see that theoretically one might want to define a transect, but do
we have any compelling use case to do this at the moment? I don't think
CMIP6 is such a case.

cheers,
Karl

On 7/1/15 6:33 AM, Hedley, Mark wrote:
> Hello Martin,
>
>> 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.
> I don't think it can be done. I agree with your analysis, the only reference to bounds is with regard to cell boundaries. It think it is sensible to keep it this way and provide a separate mechanism for your transect use case. I think overloading the current bounds mechanism is likely to lead to problems.
>
>> 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.
> It would be good to consider if this could be defined for the transect, so that standard_name descriptions can remain unchanged. I'll think on this some more.
>
>> 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.
> excellent.
>
> I'll follow up on this soon
> mark
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri Jul 17 2015 - 09:21:10 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

⇐ ⇒