Hello Jonathan > The reason why this is hard to settle is that, as we have agreed, it has no > implication at all for the netCDF file. It is just a matter of interpretation.
This doesn't seem right to me, my thought process is addressing how we encode concepts and what concepts are allowed to be encoded. I do not want to see this limitation in what can be encoded adopted by the community. Of equal note is how we interpret data which has already been encoded. > That means you have to decide which kind a scalar coordinate variable is > representing. I think the convention (up to CF 1.5 - see DSG email) implies > that if it's a numeric scalar, it's a size-one dimension coordinate > construct, and if it's a single string, it's a size-one auxiliary coordinate > construct. The principle of deciding what type of vector coordinate and what characteristics that vector coordinate should have based on contextual information on the data variable is a flawed approach which will bring further pain for creators and users of data. I think this has been a significant part of the problem so far. I also do not think that we should try to deal with the discrete sampling geometries independently, I think introducing further special cases to base decisions on exacerbate this issue. > You are concerned this restricts your flexibility. I see why you say that, of > course, but practically speaking I don't think it does. You can't leave it > undecided what a scalar coordinate means (according to my view), but nothing > prevents you from following a different interpretation to the above when you > read the file. I am not proposing leaving the meaning of a scalar coordinate variable undecided. I think it should be well defined, in a simple and clear manner. I am proposing that a scalar coordinate variable defines a coordinate which does not vary with any dimension of the data. Any implication of unencoded dimensionality is then left to the data consumer to infer if they see fit. > That may mean you have adopted a different view from the person who created > the file, but if that person did not *want* to make it clear what sort it was > (which is what you suggest) then surely he or she does not mind which > interpretation you adopt. Equally, you can read the file with one > interpretation, and then change your mind when it's in memory, by converting > dimension coordinate constructs to auxiliaries or vice-versa, creating or > dropping size-one dimensions. This is all easy to do in memory. The data is > completely unaffected, apart from being possibly reshaped by the insertion or > removal of size-one dimensions. It just shuffles the metadata around. In this context I would like to turn the point around. If the scalar coordinate variable is defined as I have proposed, your discussion makes it clear that the interpretation you desire from your use of the scalar coordinate variables is always available to you. This leads me to conclude that the simplest solution, addressing our use case, your use cases and the discrete sampling geometries issues, is the one I have proposed. As I see it, the proposal I have put forward is of no cost to your use cases and considerable benefit to mine. It simplifies the interpretation of CF NetCDF files by introducing a new type which is clearly defined semantically and within the encoding. mark
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
