timeSeries featureType with a forecast / reference time dimension?

[dblodgett-usgs]

Dear All,

There's been some question as to whether a timeSeries featureType is allowed to have a "reference time" dimension in addition to a "valid time" dimension as in a forecast model run collection. See: Unidata/thredds#1080

Is Mandatory space-time coordinates for a collection of these features of x(i) y(i) t(i,o) in the table here. to be interpreted as limited to t(i,o) or not limited to t(i,o) ? @cofinoa and I agree that it should be "not limited to" but I wanted to poll the community and get the take of those with a bit more background on the CF convention language.

Thanks!!

• Dave

Closure Criteria:
This issue should be closed when this question is answered. It may propogate an additional issue to clarify the text in the CF spec, but I would consider that an additional issue with it's own description.

[JonathanGregory]

Dear Dave @dblodgett-usgs

This issue is an old one (from three years ago) that has gone dormant, it appears. I have now labelled it as a defect issue because it's a problem with the conventions document being unclear. Since this issue is in the conventions repo, we should make a definite proposal here. (Alternatively, if you would like to have a longer discussion, you could close this issue and open an issue as a question in the discuss repo.)

I agree with you and Antonio @cofinoa in your interpretation, so I would propose that we amend the document by adding another sentence to the caption of Table 9.1: "Other space-time coordinates may be included which are not mandatory." This repeats a point which is already made in the paragraph just below the table, but there's no harm in making it more prominent by repetition, I think. Also, I propose that we insert your example in the relevant sentence in that paragraph, so it would read "However, a featureType may also include other space-time coordinates which are not mandatory (notably the z coordinate, and for instance a forecast_reference_time coordinate in addition to a mandatory time coordinate)."

If no-one objects to this being treated as a correction to a defect, or to my proposed correction, then it will be accepted in three weeks from now (6th Jan).

Jonathan

[davidhassell]

I agree with the "not limited to" interpretation, and am happy with Jonathan's proposed text.

Thanks, David

[JonathanGregory]

Please could someone merge this pull request, which qualifies for acceptance today. Thanks.

[erget]

@JonathanGregory which PR is associated with this issue? I don't see one linked.

[JonathanGregory]

Aha! Quite right. I did only half the job. :-) I will write the PR.

[JonathanGregory]

The PR is #346

[erget]

Thanks @JonathanGregory . If you have no objections, I'll set a reminder to myself to merge this in 3 weeks (2022-01-27) so that interested parties can comment on the small modifications to the updated draft in good time.

[JonathanGregory]

Thanks

[davidhassell]

Thanks, Jonathan - The PR looks fine to me.