Hi @davidhassell,
I am in favor of your version of the "computational precision" paragraph: it
conveys all the required information while remaining concise and yet clearly
warns users about the limited scope of the `computational_precision` attribute.
--
You are receiving this because you are
Thank you for the comments @AndersMS and @erget.
I like the concise version too, I would just keep my version of the "As an
example ..." paragraph even if it is more verbose because it states exactly
what the attribute means, hopefully leaving no room for misinterpretation.
The "{...] using
@AndersMS: yes I think replacing "sample/sampled" with "subsample/subsampled"
would make the text more consistent.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hi,
Here is a new take on the computational precision paragraph:
8.3.8 Computational Precision
The accuracy of the reconstituted coordinates will depend on the degree of
subsampling, the choice of interpolation method and the choice of the
floating-point arithmetic precision used in the
Hi David,
> I did indeed mean "instead of" rather than "in addition to". Allowing a
> domain variable reference instead of the usual attributes would neither
> disallow the usual attributes, nor change their meaning, so no backwards
> incompatibility. This is similar to the `grid_mapping`
Hi @JonathanGregory
> I think that allowing data variables to refer to the domain with a single
> reference _instead_ of providing the domain information by various references
> on the data variable would be a drastic change to the convention. Although
> not backwards incompatible in the
@davidhassell Sorry for the delay I just came back from vacation.
> My original comments about backwards compatibility weren't strictly right, I
> realise. Allowing a domain variable reference _instead_ of the usual data
> variable attributes would not be a CF backward compatibility issue
Sorry for the confusion between field/data and construct/variable.
My question was about having a reference to the domain variable **in addition**
to the attributes that already describe the domain (implicitly) on the data
variable so I am not sure how it would break backwards compatibility.
I
We are also in support of @davidhassell 's proposal.
Several field variables may share the same domain (output parameters computed
on the same grid for numerical model simulations, measurements and derived
geophysical data acquired by an instrument in remote-sensing, etc...) but the
current
