https://urldefense.us/v3/__https://cfconventions.org/Data/Trac-tickets/145__;!!G2kpM7uM-TzIFchu!gs_5VAu4MA3Y_uUdM-pMgAr1tV-bRFJwtAFc6ZhhIFlTaHZhMQgmRSeCmUIzKt2fraHLH_bVkxQ$
 

V. Balaji                              Office:     +1-609-452-6516
Advanced Computing Projects            Mobile:     +1-917-273-9824
CIMES/GFDL                             Email:
***@***.***://https://urldefense.us/v3/__http://www.gfdl.noaa.gov/v-balaji-homepage__;!!G2kpM7uM-TzIFchu!gs_5VAu4MA3Y_uUdM-pMgAr1tV-bRFJwtAFc6ZhhIFlTaHZhMQgmRSeCmUIzKt2fraHLCu9J7aU$
 



On Thu, Mar 10, 2022 at 1:58 PM Chris Barker ***@***.***>
wrote:

> As we all know, CF data (or model results, anyway) are often associated
> with a particular grid specification.
>
> This could be a simple rectangular grid, or a more complex grid, such as
> those defined by the UGRID and SGRID specs.
>
> It's a common practice to store the grid definition in the same file as
> the data itself, which works out fine. But in some cases, the grid
> specification may be substantial, and so it can be stored in a separate
> file, so it doesn't need to be repeated.
>
> In that case, there needs to be some way to find that other file, and,
> ideally, determine that it is, indeed, the correct grid. Various folks are
> doing this already, but not in a standard or robust way -- so It would be
> nice to have an standard way to do that in CF.
>
> I'm pretty sure I recall some previous discussion about this, but was not
> able to find it -- thus the new issue.
>
> But please feel free to redirect this discussion to an existing issue if
> there is one.
>
> I bring this up now because there was a proposal on the UGRID spec site:
>
> ugrid-conventions/ugrid-conventions#59
> <https://urldefense.us/v3/__https://github.com/ugrid-conventions/ugrid-conventions/issues/59__;!!G2kpM7uM-TzIFchu!gs_5VAu4MA3Y_uUdM-pMgAr1tV-bRFJwtAFc6ZhhIFlTaHZhMQgmRSeCmUIzKt2fraHL_3_Nk08$
>  >
>
> But it would really be nicer to have a way to do that for any grid type in
> CF itself.
>
> I refer you to that discussion for a more fleshed-out idea. If the UGRID
> community wants to take this up, I recommend we move the discussion from
> the UGRID repo to here.
>
> —
> Reply to this email directly, view it on GitHub
> <https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/357__;!!G2kpM7uM-TzIFchu!gs_5VAu4MA3Y_uUdM-pMgAr1tV-bRFJwtAFc6ZhhIFlTaHZhMQgmRSeCmUIzKt2fraHLIsyWoys$
>  >, or
> unsubscribe
> <https://urldefense.us/v3/__https://github.com/notifications/unsubscribe-auth/ABQJZVGGJF4YVCI5PVHVBF3U7JA6LANCNFSM5QNQN6QQ__;!!G2kpM7uM-TzIFchu!gs_5VAu4MA3Y_uUdM-pMgAr1tV-bRFJwtAFc6ZhhIFlTaHZhMQgmRSeCmUIzKt2fraHLnflqjXU$
>  >
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://urldefense.us/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!G2kpM7uM-TzIFchu!gs_5VAu4MA3Y_uUdM-pMgAr1tV-bRFJwtAFc6ZhhIFlTaHZhMQgmRSeCmUIzKt2fraHL23mDsbA$
>  >
> or Android
> <https://urldefense.us/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!G2kpM7uM-TzIFchu!gs_5VAu4MA3Y_uUdM-pMgAr1tV-bRFJwtAFc6ZhhIFlTaHZhMQgmRSeCmUIzKt2fraHLfnsDQqg$
>  >.
>
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>


-- 
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/357*issuecomment-1064465581__;Iw!!G2kpM7uM-TzIFchu!gs_5VAu4MA3Y_uUdM-pMgAr1tV-bRFJwtAFc6ZhhIFlTaHZhMQgmRSeCmUIzKt2fraHLi_D89h8$
 
You are receiving this because you are subscribed to this thread.

Message ID: <cf-convention/cf-conventions/issues/357/[email protected]>
This list forwards relevant notifications from Github.  It is distinct from 
[email protected], although if you do nothing, a subscription to the 
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to 
[email protected].

Reply via email to