Dear Jonathan, Looks good - no objection from me. Do you want to write a Pull
Request?
Thanks,
David
--
Reply to this email directly or view it on GitHub:
@davidhassell approved this pull request.
--
Reply to this email directly or view it on GitHub:
I support this, too.
--
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/363*issuecomment-1106184279__;Iw!!G2kpM7uM-TzIFchu!jnsr_0PE0nx0OqAguFODBBxbgIY1wlgzBn68cj6aV7YrJB4-9kf2qysM8xvM-O1YYA98WZu0Zrc$
You are
Merged #351 into main.
--
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/351*event-6037923035__;Iw!!G2kpM7uM-TzIFchu!mbCX7jteYxYbUvnSxb9Z3MzO_EX9Fc8joVlvBebWKmctZ_wGYsxaY-VVqJWGj-yiYAf3DpGKJfA$
You are
Closed #352 via #351.
--
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/352*event-6037923068__;Iw!!G2kpM7uM-TzIFchu!md6sgOXyfHUbyYvlM86gi8F03o_JmZTKgSY9-8I5KdBuufg9apTX_OewDbTh-lJvEkWBw56jnWI$
You are
Hello, no one has objected to these defect corrections for over three weeks, so
according to the rules they may be accepted. I shall the associated Pull
Request.
Many thanks, David
--
Reply to this email directly or view it on GitHub:
Hello,
I agree with Dave that there are no rules on that, but I'd like to fully
understand what you are suggesting for polygons. Do you mean "are different
_parts_ of a multi-part polygon allowed to overlap" or do you mean "are
different _edges_ of an individual polygon part allowed to
Dear Jonathan,
I have made some commits that hopefully make clearer the relationship between
CF-netCDF mesh topology and location index variables, and CF data model Domain
and Domain Topology constructs. What do you think?
@davidhassell pushed 1 commit.
c401fae05d15f4aba7df1a2fe69163a8f00d389e describe relationship between domain
construct and CF-netCDF variables
--
View it on GitHub:
@davidhassell pushed 2 commits.
d0377b02d78f455698283140564f38db528602a8 typo
3f9b4d53421f7da8c380c7e489e7713140edc60a describe relationship between domain
construct and CF-netCDF variables
--
View it on GitHub:
Dear Jonathan,
Thank you for your comments.
> In Appendix I (the data model), you describe the new CF-netCDF element as
> "Domain(s) with cell connectivity" and the new CF construct as "Connectivity
> of domain cells". I wonder if these should be the same.
Good point, In this case I think
Hello all,
I have created a couple of pull requests to hopefully finally get UGRID into
CF. I've not consulted anyone on the new text yet, so I fully expect some
constructive comments! but I thought it a good idea to have something that we
can discuss in less abstract terms.
I have copied the
See issue #153 for discussion of these changes. This PR also depends on
placeholder
# Release checklist
- [ ] Authors updated in `cf-conventions.adoc`?
- [ ] Next version in `cf-conventions.adoc` up to date? Versioning inspired by
I support this as well.
--
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/349*issuecomment-1009170086__;Iw!!G2kpM7uM-TzIFchu!lTsrcTjgK5abuDw17MwA1YdILRt_HAqufXAFSxX9gAfpBTvh18RpRh7_PDC8Sw1hvnkiMK9bwms$
You
Dear Jonathan,
You can see the milestone, but it's easy to miss, as it's not formatted the
same as a label:
Hello all,
My (current) thoughts on the new release question: I'm not sure about cutting
1.10 to fix just this defect. Given that it can be fixed in the latest CF-1.10
draft, is that not sufficient to tide us over to the whenever CF-1.10 is
released? A few years ago we agreed that one release,
Thanks, Jonathan - The PR looks fine to me.
--
Reply to this email directly or view it on GitHub:
I agree with the "not limited to" interpretation, and am happy with Jonathan's
proposed text.
Thanks, David
--
Reply to this email directly or view it on GitHub:
Hi all,
I'm still re-assimilating what went on here, but it occurs to me that allowing
data type equivalence (rather than equality) is problematic:
* The `missing_value` and `_FillValue` (and the `valid_*` attributes) must be
of the same data type as the data to which they apply, so if they
Hi @martinjuckes,
Yes, of course! I notice that my offer came just before everything changed last
year, so I guess it got lost in the noise. I shall remind myself of the
discussion thus far and post a summary.
Thanks,
David
--
You are receiving this because you are subscribed to this
Hello,
I'd just like to advertise that discussion of this issue has now been added as
breakout session in next week's online CF meeting
[List of pull requests that contributed to
CF-1.9](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pulls?q=is*3Apr*milestone*3A*221.9*22*__;JSslJSUr!!G2kpM7uM-TzIFchu!hTpbep5QLPz7rz52VBHnCcDCsJx_BMStCE0l1OJL5U6pShlVHEpIrZJvgtcisIIjjV89IqCB31o$
)
--
You are receiving
Merged #338 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@davidhassell pushed 1 commit.
a22f023c5e647941a135d07b80b56a06ce159fdb note when new appendices appear
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
No associated issue - editorial fix.
# Release checklist
- [x] Authors updated in `cf-conventions.adoc`?
- [x] Next version in `cf-conventions.adoc` up to date? Versioning inspired by
@davidhassell pushed 1 commit.
ba9e355f3b3ba92395a721daf0b4f5d38051c8f9 fix spelling mistakes
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Hi @erget - we list by issue, rather than PR, so it's there under 258:
```
.02 June 2020
. link:$$https://github.com/cf-convention/cf-conventions/issues/258$$[Issue
#258]: Clarification of geostationary projection items
```
Is that OK?
--
You are receiving this because you are subscribed to
See issue #XXX for discussion of these changes.
# Release checklist
- [x] Authors updated in `cf-conventions.adoc`?
- [ ] Next version in `cf-conventions.adoc` up to date? Versioning inspired by
Merged #324 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #323 via #324.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Got it, thanks. Please merge!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks, @erget. I'm not sure what was introduced before, but adding the label
looks good to me.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hello @ninsbl,
There was a good discussion on skin and surface temperatures over land and sea
back in 2013 (unfortunately the
Hi Ken,
Sorry to have abandoned this again. Your proposal is clearly workable in
practice, but there are some issues with the implementation, of varying degrees
of seriousness, that mean that it is not yet suitable for inclusion into CF. I
agree that it seems like a minimally intrusive set of
Using okular, I see the boxes, too. However, viewing the file with the built-in
Firefox PDF viewer, I see just a space with no box outlining box.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think that it should indeed have happened. The raw `.adoc` files have clearly
been updated in the `master` branch. The previously merged PR is visible in the
on-line latest
@davidhassell commented on this pull request.
> @@ -606,7 +606,7 @@ For the reconstituted coordinates, cell bounds are stored
> separately for each co
for the example of 2D bounds. Since the cell bounds are contiguous, bounds
points of adjacent cells will coincide and so the full set of
Hi @ChrisBarker-NOAA,
This puzzled me for a bit, until I remembered that in the CF data model, DSGs
are _not_ special. This is because what looks like a discrete axis in the
encoding of a DSG is a really just a form of lossless packing for an orthogonal
multidimensional array (with the data
Dear @JonathanGregory,
Thanks for your comments.
> I think that "unlike" implies it's somehow inconsistent ...
Agreed. With your new text, that last paragraph becomes
In CF-netCDF a domain topology can only be provided for a domain defined by a
UGRID mesh topology variable. In this case, the
@davidhassell pushed 1 commit.
c1bc014a8267a56c499bef2b8054a36a7704ee1a history for #323
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Thanks Dave, Jonathan and Karl. I'll update `history.adoc`, and unless anything
else crops up we can merge this in two weeks.
David
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hi @ChrisBarker-NOAA,
> The whole concept of an "axis" matches orthogonal coordinates of some sort.
> (that's kind the definition of orthogonal, yes?). Mapping a Ugrid to the real
> world, the real world is 2D (Or 3D, but let's not go there yet) -- and that
> 2D world has 2 orthogonal axis --
Hi @ChrisBarker-NOAA and @pp-mo,
I have been away and am just catching up with the conversation. Thank you for
an interesting read!
> From the data model perspective, there needs to be SOME way to define the
> connectivity. how it's done is a matter of the "encoding", yes?
Absolutely.
Dear @JonathanGregory, @AndersMS, and all,
> Conformance
>
> For "Each tie_point_variable token specifies a tie point variable that must
> exist in the file, and each interpolation_variable token specifies an
> interpolation variable that must exist in the file," I think all you can say
> is
Created in error - sorry!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #333.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
See issue #XXX for discussion of these changes.
# Release checklist
- [ ] Authors updated in `cf-conventions.adoc`?
- [ ] Next version in `cf-conventions.adoc` up to date? Versioning inspired by
Hello @ChrisBarker-NOAA and all,
After some very illuminating discussion over at
https://urldefense.us/v3/__https://github.com/ugrid-conventions/ugrid-conventions/issues/52__;!!G2kpM7uM-TzIFchu!gsrPpUHyBO1L3RCLlnbI4ykGpE8GyFUQGCnBa97TVwjO6tJnc_z4tfusXiad6JE3NXdsbwwppNw$
, and some offline
Hi Ken,
I'm sorry that this has stalled, but I don't have as much time as I would like
to devote to as many lengthy and involved proposals as I might like. Perhaps
when some other CF issues I've been involved with for some time have concluded
I will have more time here.
There are still many
> Maybe we could append a new item at the end of "Coordinate Compression Steps"
> in Appendix J recommending that data producers check the positional error by
> comparing the reconstructed coordinates against the original data, and then
> provide as many details as possible regarding the
@davidhassell commented on this pull request.
> + Tie Point Dimension Mapping
+
+The **`tie_point_mapping`** attribute defined above associates
+each interpolated dimension with its corresponding subsampled
+ dimension and, if required, its corresponding
+ __interpolation subarea
@davidhassell commented on this pull request.
> +alignment. As an example, such discontinuities are common in remote
+sensing data and may be caused by combinations of the instrument scan
+motion, the motion of the sensor platform and changes in the
+instrument scan mode. When discontinuities
@davidhassell commented on this pull request.
> +contain discontinuities. A discontinuity could be an overlap or a gap
+in the coordinates' coverage, or a change in cell size or cell
+alignment. As an example, such discontinuities are common in remote
+sensing data and may be caused by
Hi all,
Sylvain's descriptions and rational are very good, I think. I am wondering,
however, if we are making too bold claims about accuracy when we have no
control over the interpolation method's implementation. A user's technique
may differ from the creator's (that's OK), but if one
Thanks, Klaus and Jonathan - This alternation
(https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/331/commits/bd7498d3625a1ee464f375952bfd202f7fbc4371__;!!G2kpM7uM-TzIFchu!h4CVLsFmCw8V3-WerXXaZc2QxZKN9J3yJ7tE4mBK6oHFEa6yN_9Hk52Gx4Cj75L5v2_cUvflBuA$
) looks good to
Thanks, @JonathanGregory. Your PR looks good to me.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
Thanks to @JonathanGregory for putting together the pull request that will
close this issue (as well as #298). This PR (#331) should be merged on 23rd
July, three weeks from today, if no concerns are raised.
--
You are receiving this because you are subscribed to this thread.
Reply to this
Dear Patrick,
Thank you for bringing up "location index set" variables. I agree that in the
absence of the `cf_role` attribute it is not always possible to distinguish one
from data variable, so I would be happy with retaining it on these variables.
By extension, I think that we should drop
Dear Klaus,
I hope to allay your concerns by noting that all of the UGRID machinery for
storing connectivity will certainly be imported into CF unchanged - it is just
that in the logical data model we don't need to make special mention of it.
This is because it turns out the connectivity
Dear Jonathan,
That's right. I should have made that clearer, so many thanks for pointing it
out!
CF provides cell connectivity by inspection of coincident (or possibly
overlapping) bounds.
UGRID provides an index based encoding for making the connectivity easier to
find in many
Hello,
In starting to think about:
> (H) Further to the discussion on implications on the CF data model
> (ugrid-conventions/ugrid-conventions/issues/52), the CF data model needs to
> be updated to allow the storage of topological connections between cells
> ("cells" in the CF data model
Hi Anders,
> I believe the following paragraph from our chapter 8 is no longer relevant
I do agree.
David
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The changes agreed here will now be incorporated into the wider-ranging changes
of #298 "_Interpretation of negative years in the units attribute_"
Thanks @JonathanGregory - I'm happy with your latest proposed text; and thanks
@semmerson for putting us right :)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
Hello Lars,
I like your suggestions.
With regards Udunits, the time units are distributed across multiple XML files.
For example, `hour` is defined in `udunits2-accepted.xml` and `second` is
defined in `udunits2-base.xml`. Perhaps it might be better to say:
"The acceptable units for time are
> it could be convenient if no-one objects to merging them
It is fine by me.
> I did in in a different way, by stating that months are of Gregorian lengths.
Which I think works well!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Thank you, Jonathan. Your text is very clear to me.
All of the changes required for #319 are now here - is it OK for #319 to just
refer to the PR for this issue, rather removing these changes from this issue
and recreating in a bespoke PR for #319?
--
You are receiving this because you are
It looks like a consensus solution has emerged:
* The `gregorian` calendar is deprecated.
* The default calendar is redefined as `standard` alone.
* The `noleap` and `all_leap` calendars are both redefined to be modifications
of the proleptic gregorian calendar.
Does that sound right?
Thanks, all. I would probably go for the "leave the past documents unchanged
for the sake of immutability and simply include the dates in future versions"
at this time.
If we wanted to do something different in the future, the approach of making a
1.7.1 branch from the 1.7.0 tag sounds very
That looks good to me, Anders. The word _computation_ is good.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thank you, Anders. I very happy with this.
A minor suggestion - perhaps change:
_"...may specify the floating-point arithmetic precision by setting ..."_
to
_... may specify the floating-point arithmetic precision to be used in the
interpolation calculations by setting ..._
just to be extra
Good point, @zklaus. I think that all this applies only to `gregorian`, i.e.
the `standard` calendar (= Mixed Gregorian/Julian calendar as defined by
Udunits) remains unchanged by this proposal.
In that case, we need to be clear that the default calendar has changed to
`standard`, rather than
Hello,
Following on from some discussions that have been taking place on the [UGRID
issue
tracker](https://urldefense.us/v3/__https://github.com/ugrid-conventions/ugrid-conventions/issues__;!!G2kpM7uM-TzIFchu!jNG-Y16d7c-C88U9VVZoa-yNuIMgPRCdgpg_rDn4glZ59EsZV9mellI5RhDBXtvHkx_max3jEsU$
), a
Hello,
A lot of suggestions have been made on this issue wince the last update to the
associated pull request (#315). I'm not sure if consensus has been reached, as
the conversation has paused, but is it possible for someone to synthesise the
suggestions made here during April 2021 so that the
Hello,
Here's my summary of where we are with this issue. Please say if you think that
I've misrepresented/misunderstood anything.
* The initial proposal was to redefine `gregorian` to have a distinct meaning
from `standard`, namely, `gregorian` would include the restriction that
prohibits
Closed #314 via #317.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #317 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hi Anders - thanks, it sounds like we're currently in agreement - do you want
to update the PR?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@davidhassell pushed 1 commit.
09fd4fbd429f42466d46463c6a137e5caec539fe typo
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Hello - There have been no further comments for a while - is this good to be
merged?
Thanks,
David
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hi @snowman2 - I'm not sure what is being proposed here, as such units are
[not
Hi Anders,
> "The floating-point arithmetic precision should match or exceed the precision
> specified by computational_precision attribute. The allowed values of
> computational_precision attribute are:
>
> (table)
"32": 32-bit floating-point arithmetic
"64": 64-bit floating-point arithmetic
# Conventions release dates are missing since CF-1.7
# Moderator
@user
# Requirement Summary
Recent versions of CF do not state their release date. This is useful
information for curators, creators and for the building of other standards
which rely on CF.
Since CF-1.7, the release date has
Hi Ken,
I'm trying to better understand the issues around cell methods, and would find
it very useful to have the parent data variable that goes with this example
ancillary variable the new chapter 10:
```
float relative_humidity_uncert ;
relative_humidity_uncert:long_name = "Relative
That's good for me, thanks @JonathanGregory
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hello,
Is it right that the deprecations that Ethan lists
(https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/328*issuecomment-846140071__;Iw!!G2kpM7uM-TzIFchu!hEdFbHQ7AQTo1vrmCimiywuaJ0AkwEDI3gsqODD8ZVcqeNsGUms7VVc9YDIXNN3uV1_pNk9Bzrc$
) are still allowed? i.e.
Dear Jonathan,
Oh - what a difference a day makes!
Thanks for the text. I think it is fine, but it states that it is still OK to
produce CF-1.8 datasets if they don't contain this particular formula - is that
what we want? I would have thought that the the creation of all new CF-1.8
datasets
Hello - the 20th May is here, and no further comments have arisen. Thanks to
all for the interesting discussion - and especially to @johnwilkin for the
excellent diagrams.
Before we merge, however, it is noteworthy that this issue has identified and
corrected a fundamental flaw in the
Overall, I think that the general approach of using ancillary variables and
cell methods is a good one.
There was considerable discussion around the topic of "standard name modifiers
or cell methods?" in
Dear Ken,
Thanks for putting this together - a lot of work has clearly gone into it.
I have a number of comments and questions which I'd like to think about some
more before posting, but I'd like to highlight at this time that the proposal
as it stands would require a number of changes to the
Thanks, @taylor13 and @AndersMS,
I, too, would favour A (_Using the scheme proposed above, requiring the data
creator to set the computational_precision accordingly._).
I'm starting to think that the we need to be clear about `"decimal64"` (or 32,
128, etc.). I'm fairly sure that we only want
Hi @taylor13,
1: I agree that higher precisions should be allowed. A modified description
(which could do with some rewording, but the intent is clear for now, I hope):
* By default, the user may use any precision they like for the interpolation
calculations. If the `computational_precision`
For convenience, here is the proposal for specifying the precision to be used
for the interpolation calculations (slightly robustified):
* By default, the user may use any precision they like for the interpolation
calculatins, but if the `interpolation_precision` attribute has been set to a
Hello @taylor13, @AndersMS,
It might be better to continue the conversion over at #37 on the precision of
interpolation calculations (the comment thread starting at
Hi @erget,
>From what you describe, should the dates _always_ be the date of minting a
>release, rather than the date merging. That could clear things up? I think a
>quick chat later would be good!
I'd also like to add a _merger_ item for the data model:
Merger checklist
- [ ]
- [ ]
Hi @erget,
I don't know. I had thought that we would merge PRs into master at the time of
their acceptance, so that future PRs for the same next release can build on
the accepted changes.
I may well have misunderstood things, apologies if so, but in any event, if we
say "Set the date when
Sounds good, thanks. How about:
Author checklist
- [ ] Authors updated in cf-conventions.adoc?
- [ ] Conformance document up-to-date?
- [ ] Related issues registered in history.adoc, with placeholders for the
dates?
Merger checklist
- [ ] Set dates for new history.adoc entries?
Merged #291 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #290 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hello @neumannd,
I think that there are no problems with your PR, but would you consider
updating it as per @taylor13's
1 - 100 of 290 matches
Mail list logo
