This question has been answered, add to FAQ: "Can the longitude axis 360 degrees periodicity be described in CF?"

[jypeter]

I wonder if the fact that the longitude axis (aka X axis) has a 360 degrees periodicity can be represented in CF, or if we just assume that this information is always implicit?

I also wonder which software packages use this implicit (or explicit) information, and can automatically reorder data when reading NetCDF files. e.g load data in the [-180, 180[ range, when it is stored in [0,360[ (or the reverse). This is kind of loosely related to the recent #435

• cdo can probably do that with sellonlatbox, but this does not seem to be explicitly covered by the documentation. Or I have not found it. @uweschulzweida ?
• cdms2 handled that extremely nicely, but it is being slowly phased out in favor of xarray+xcdat
• xarray and other tools ??

I had assumed until today that this X axis periodicity feature was covered in the CF convention, because I had NetCDF files with metadata looking like

        double lon(lon) ;
                lon:bounds = "lon_bnds" ;
                lon:modulo = 360. ;
                lon:realtopology = "circular" ;
                lon:long_name = "longitude" ;
                lon:standard_name = "longitude" ;
                lon:units = "degrees_east" ;
                lon:axis = "X" ;
                lon:topology = "circular" ;

But maybe that was only because these files and been generated with cdms2, and cdms2 had been originally developed by Bob Drach, the D in GDT convention. @taylor13 I have failed (again) to find the original GDT convention on Google, and I don't want to ask chatGDT to write one ;-)

I have not found any relevant information in the CF convention when I looked for the following strings: topology, circular, modulo, 360

I have also looked at MPI (trying not to use IPSL for a change) CMIP3, CMIP5 and CMIP6 orog files, but the longitude axis looked like

        double lon(lon) ;
                lon:standard_name = "longitude" ;
                lon:long_name = "longitude" ;
                lon:units = "degrees_east" ;
                lon:axis = "X" ;
                lon:bounds = "lon_bnds" ;

There is an old cdms issue related to this that gives an example of how a package can use the periodicity information, or fail if the periodicity metadata is incorrect: CDAT/cdms#371

[larsbarring]

Hi @jypeter
I might be missing something in what you ask, but here is my take on this:
The 360 degree periodicity is a fundamental aspect of longitudes simply because that is a full circle. Longitudes in the interval [-180, 180[ also have a 360 degree periodicity, so what you ask is more related to an offset (or modulo). And as explained in the comments to #435 the offset is either obvious from looking at the longitude data, or it does not matter.

Which software can/cannot make an automagic transformation between [0, 360[ and [-180, 180[ is an entirely different question, and I am not sure -- but might well be wrong -- that the presence or not of a specific attribute is essential for achieving this.

[jypeter]

Well, even if the longitudes' 360 degrees periodicity is obvious (for a human), conventions can also be used to state the obvious (or clarify ambiguities), so that computers know how to use the data

That's why I'm wondering which programs/libraries handle longitude information (including using the 360 degrees periodicity if required) correctly. Hopefully all the software our community uses, e.g those listed in Software that “Understands” CF Data

I have just found out where the CF convention explains how programs should determine that a given dimension is indeed a longitude: 4.2. Longitude Coordinate. The convention does not mention anything about handling 360 degrees periodicity.
Maybe we just have to assume that the correct longitude handling is hard-coded in the programs as soon as they recognize that a dimension is a longitude, without requiring specific periodicity metadata

[larsbarring]

Regarding longitude coordinates please note that there are some changes to the text between the current version 1.10: section 4.2 and the upcoming (draft) version 1.11: section 4.2.

[sethmcg]

@jypeter -- To be explicit (ha ha), yes, we do assume that the periodicity of longitudes is implicit, and I would argue that we should continue doing so.

The volume of existing data that makes that implicit assumption is vast, and changing the standard to make that assumption explicit would introduce a discrepancy between anything that noted it explicitly and all of that other data, which is bad. It also would do programmers no favors, as they'd still have to figure out what to do when it wasn't explicit.

(Also, what would it mean to declare a longitude as not periodic, which is a possibility opened up by making it explicit?)

I think it's better to leave 360-degree periodicity as implicit because it's part of the definition of longitude, just like a range of [-90:90] is to latitude, and say that programs that need to deal with it should learn those definitions, rather than trying to pull the information out of the definition.

[davidhassell]

I agree with much that has been said here, very nicely summed up by @sethmcg in his previous post (#439 (comment)), in particular the observation that "it is part of the definition of longitude".

Whether or not the two end cells of the array are adjacent in physical space, and can therefore be rearranged to next to each other (e.g. rearranging [-180, 180) to [0, 360)), is a different matter. If you wanted the rearrangement be contiguous then you'll want to check for global data by inspection of the coordinate bounds to see whether or not their extrema are the same modulo 360. You can of course rearrange in any event, if you want to, regardless of this check - it'll still be self-describing and CF-compliant.

It is possible for library software to automate all of these situations, as cf-python does, for example.

[JonathanGregory]

This question has been answered, but I propose we keep the issue open until it has been added to the FAQ.