standard names for vector components

[markh]

Objective

A reinterpretation of current standard names to make the identification of vector components clear and able to meet the needs of users.

This issue is related to the proposal on #79

Proposal

To adopt the constrained standard name concept to re-interpret vector quantity standard names, without invalidating any current datasets. This would involve:

• 'x_' type standard names being valid for all coordinate definitions:
  • '"x" indicates a vector component along the grid x-axis, positive with increasing x.'
• 'eastward_' type standard names being valid for all 'true east' vectors:
  • '"Eastward" indicates a vector component which is positive when directed eastward (negative westward); where eastward is defined as the grid x-axis direction, this is a constrained version of the "x_" standard name';
  • this may be interpreted in two ways, as:
    1. where eastward is defined as the grid x-axis, this standard name is a constrained version of x_wind
    2. where eastward is not defined as the grid x-axis, this standard name stands independently

This enables data producers to use eastward wind in the same way they currently do, while meeting my requirements, for datasets where x may or may not be east, depending on the location and for data format interoperability with formats which do not have an explicit 'eastward_' phenomenon definition.

It enables datasets to be written where:

• vector is x but not east
  • standard_name: x_<>
• vector is x and may be east or eastish
  • standard_name: x_<>
• vector is x and happens to be always east
  • standard_name: x_<>
• vector is x constrained to always be east
  • standard_name: eastward_<>
• vector is east but not x
  • standard_name: eastward_<>

'eastward_<>' is already interpreted in multiple ways, depending on the coordinate variable context of the dataset. 'x_<>' should also be abe to be interpreted based on coordinate variable context, to enable datasets to be encoded which currently cannot be written in a CF compliant fashion

Analogy

This approach, of constraining standard names, is analogous to qualification. For example:

• there is a standard name of air_pressure
• this could be defined, for a particular dataset, such that the vertical coordinate indicates that the data is at a surface
• if the fact that the dataset is at a surface is intrinsic to the data, the qualified (constrained) standard name may be used: surface_air_pressure

[jonathan]

Dear Mark

I appreciate that you are proposing a way to reconcile your needs with the objection that was made on the email list. However, the distinction you are drawing here is rather subtle! While respecting this attempt at consensus, I wonder if it would be more straightforward to recognise that different needs require different standard names. It is not the business of CF to tell people what quantities they should use, but only to define names for the quantities they want to use.

If I remember correctly, the reservation expressed originally was that if the quantity is eastward, it should be called eastward, even though it may also be xward, because eastward is more generally useful and independent of the coordinate system. In a way this is analogous to air_pressure and surface_air_pressure, the latter being more specific. It would not be helpful to use the generic name if you meant the specific name, because there are several ways you could indicate the surface with a coordinate variable (e.g. height=0, depth=0, altitude coincident with surface_altitude) and it would be asking a lot to expect a generic application to work out it was surface air pressure that you meant.

I agree with the reservation expressed that it is less helpful to the data user to use a general vector component name when you could use a specific one. However I also agree with you that it is legitimate to do so. I suggest (as on the email list) the clearest way to resolve this is to define new names specifically for your purpose e.g. x-components named as such even when xward is eastward.

Best wishes

Jonathan

[markh]

Replying to jonathan:

If I remember correctly, the reservation expressed originally was that if the quantity is eastward, it should be called eastward, even though it may also be xward, because eastward is more generally useful and independent of the coordinate system.

This is the part I disagree with. I think it is the responsibility of the data producer to make this decision, not the job of the CF standard names definitions.

Where x != eastward, the definitions are mutually exclusive, but where they are not, I feel that the data producer should be allowed to pick which standard name better represents their data.

In a way this is analogous to air_pressure and surface_air_pressure, the latter being more specific. It would not be helpful to use the generic name if you meant the specific name, because there are several ways you could indicate the surface with a coordinate variable (e.g. height=0, depth=0, altitude coincident with surface_altitude) and it would be asking a lot to expect a generic application to work out it was surface air pressure that you meant.

It is not truly analogous, as 'eastward_' is not more specific than 'x_', it can be used for eastward where this is not xward.

I need the ability to create a dataset where the standard_name is defined with respect to x and where that x may or may not be eastward. This is currently banned by the standard name definitions.

This is required as I have datasets where the relationship between x and eastward is position dependent. In this case there is no valid standard name that I can use for my data.

I agree with the reservation expressed that it is less helpful to the data user to use a general vector component name when you could use a specific one. However I also agree with you that it is legitimate to do so. I suggest (as on the email list) the clearest way to resolve this is to define new names specifically for your purpose e.g. x-components named as such even when xward is eastward.

I do not think this addresses the issues described. If I introduce a new standard name:

• 'x_eastward_wind' for datasets where x is east, then I still do not have a valid standard name for my use case, when eastward is xward for -ve latitude and not xward for +ve latitude.
  • how does a data producer decide which standard name to use for eastward wind where east is x? Is eastward_wind still valid for this case? (it must be if we are not to invalidate current datasets)
• 'xward_wind' where x may be east
  • how does a data producer decide which standard name to use for wind in an xward direction?

As such I am not in favour of adding new standard names, particularly given how many would be required. In both cases we would have to accept the position that multiple standard names exist, which a data producer has to choose between, to provide their data with a standard name.

I feel we need to accept this position, and that once we do, there is no need for more standard names, as the standard names we currently have are then sufficient for our needs; as of now the restriction on the use of x when x is eastward is overly restricting us.

I feel that this proposal addresses the need while maintaining all current uses of these standard names.

I agree that this change means that it is possible that a dataset I create may be eastward wind, but a data consumer might not realise this, but I feel this is a price I accept as a data producer. My decision as a data producer is to use x-wind because I feel this is the best description of my data and that eastward is not a vital characteristic of the physical phenomenon.

The important note here is that no current or future data which is currently valid has it's meaning changed by this proposal. The standard names and their interpretations are still all valid.

I am asking for a relaxation in how x/y may be applied to increase their usefulness.

I know of many datasets which use x_* in this way, despite the restrictions in the standard name interpretation, so in a sense I am asking for the definitions to catch up with common use.

[jonathan]

Dear Mark

It could be argued that this relaxation does involve a change to the interpretation of existing data, because where archived data says "x" it might currently be assumed that this means it is definitely not "eastward". Once this change was made, you could not assume that any more. Of course, you could compare the date of the data with the date when the convention was changed, but that would be a nuisance.

I think we may be trying to be too subtle with the interpretation. I would argue that this is a straightforward choice. Either we decide that in existing (and new) standard names "x" is allowed even when "x" happens to coincide with "east" (what you propose), or we decide that this is not allowed (in which case I can't see how to provide what you need except by using new standard names). I also fear that few people apart from you and me are listening to this conversation, since trac tickets aren't widely distributed, as we know. Therefore, although it's where you started, I suggest that you might try again on the email list, presenting the question as a simple Yes/No? choice, and inviting subscribers to the list to reply "Yes" or "No"!

I don't know how many will reply, but if it is quite a few, that might be annoying to subscribers to the list. Therefore perhaps it would be more polite to ask people to email "Yes" or "No" to mark.hedley@… and j.m.gregory@… instead of the email list, and we can report the results (if any) after a few days.

Best wishes

Jonathan

[markh]

Replying to jonathan:

Dear Mark

It could be argued that this relaxation does involve a change to the interpretation of existing data, because where archived data says "x" it might currently be assumed that this means it is definitely not "eastward". Once this change was made, you could not assume that any more.

You are correct, this reinterpretation is a consequence of the proposal.

I think we may be trying to be too subtle with the interpretation. I would argue that this is a straightforward choice. Either we decide that in existing (and new) standard names "x" is allowed even when "x" happens to coincide with "east" (what you propose), or we decide that this is not allowed (in which case I can't see how to provide what you need except by using new standard names).

I agree with the way you state the 'simple choice'. I think that this ticket indicates the implications of allowing 'x' when 'x' happens to be 'east'. I might describe it as 'just subtle enough' but that's just my perspective.

I also fear that few people apart from you and me are listening to this conversation, since trac tickets aren't widely distributed, as we know. Therefore, although it's where you started, I suggest that you might try again on the email list, presenting the question as a simple Yes/No? choice, and inviting subscribers to the list to reply "Yes" or "No"!

Hopefully Jeff's change will mean that this posting will also appear on the mailing list. Therefore I ask that people with an interest express their 'yes' or 'no', either on this ticket, or via email to mark.hedley at metoffice.gov.uk and j.m.gregory at reading.ac.uk to this proposal.

If the consensus is not to accept this interpretation then my next step will be to request a large number of new standard names which extensively overlap with the current standard names, which I feel causes many more issues than the reinterpretation proposed here.

for example:

xward_wind: "x" indicates a vector component along the grid x-axis, where this may or may not be true longitude, positive with increasing x. Wind is defined as a two-dimensional (horizontal) air velocity vector, with no vertical component. (Vertical motion in the atmosphere has the standard name upward_air_velocity.)

[eaton]

I agree with this proposed change.

[mcginnis]

I agree with Mark, and support the change.

Relaxing the constraint seems to me far, far less likely to cause confusion than the alternative. I'm also having trouble imagining a situation where being able to assume that x-ward != eastward is a useful enough distinction to be worth preserving.

[ngalbraith]

We have to trust that folks writing data will want to do so in a way that makes that data most easily discovered (and correctly used) by others. I just don't see any likely scenario where this minor change would lead to data being mislabeled or incorrectly interpreted.

So, I agree with Mark's proposal - there doesn't seem to be an actual down-side.

[caron]

I think this is a good clarification and i support the proposal.

[lavergne]

Replying to markh:

I agree: this is a good clarification and support this proposal.

[jonathan]

Evidently plenty of people support this change. So do I. Sufficient support has already been expressed for it to be accepted. I propose that we follow the normal rule, that the proposal will be accepted if no-one objects within the next three weeks.

Thank you, everyone.

Jonathan

[jonathan]

Alison made the required changes to the definitions of standard names in version 21 of the standard name table in Jan 2013. Thank you, Alison.