Repository: ioos/compliance-checker

Issue:
Test "dimension_order" with inconsistent results
This [file](http://thredds.aodn.org.au/thredds/catalog/IMOS/eMII/checker_test/ANMN/timeSeriesProfile/catalog.html?dataset=eMII/checker_test/ANMN/timeSeriesProfile/IMOS_ANMN-QLD_AETVZ_20110307T111900Z_GBRHIS_FV00_GBRHIS-1103-Workhorse-ADCP-model-Sentinel-or-Monitor-44_END-20110813T105900Z_C-20160203T040408Z.nc) and this [one](http://thredds.aodn.org.au/thredds/catalog/IMOS/eMII/checker_test/ANMN/timeSeriesProfile/catalog.html?dataset=eMII/checker_test/ANMN/timeSeriesProfile/IMOS_ANMN-QLD_AETVZ_20110307T111900Z_GBRHIS_FV01_GBRHIS-1103-Workhorse-ADCP-model-Sentinel-or-Monitor-44_END-20110813T105900Z_C-20160203T040408Z.nc) both include VCUR or VCUR_MAG such as:

```
float VCUR(TIME, HEIGHT_ABOVE_SENSOR) ;
                VCUR:coordinates = "TIME LATITUDE LONGITUDE HEIGHT_ABOVE_SENSOR" ;
                VCUR:standard_name = "northward_sea_water_velocity" ;
                VCUR:long_name = "northward_sea_water_velocity" ;
                VCUR:units = "m s-1" ;
                VCUR:valid_min = -10.f ;
                VCUR:valid_max = 10.f ;
                VCUR:_FillValue = 999999.f ;
                VCUR:comment = "magneticDeclinationPP: data initially referring to magnetic North has been modified so that it now refers to true North, applying a computed magnetic declination of 9.7degrees. NOAA\'s Geomag v7.0 software + IGRF12 model have been used to compute this value at a latitude=-23.5136degrees North, longitude=151.9553degrees East, depth=44m (instrument nominal depth) and date=2011/05/25 (date in the middle of time_coverage_start and time_coverage_end)." ;
                VCUR:ancillary_variables = "VCUR_quality_control" ;
                VCUR:magnetic_declination = 9.7 ;
                VCUR:compass_correction_applied = 9.7 ;
```

with

```
double TIME(TIME) ;
        TIME:standard_name = "time" ;
        TIME:long_name = "time" ;
        TIME:units = "days since 1950-01-01 00:00:00 UTC" ;
        TIME:calendar = "gregorian" ;
        TIME:axis = "T" ;
        TIME:valid_min = 0. ;
        TIME:valid_max = 90000. ;
```

and

```
float HEIGHT_ABOVE_SENSOR(HEIGHT_ABOVE_SENSOR) ;
        HEIGHT_ABOVE_SENSOR:comment = "Data has been vertically bin-mapped using tilt information so that the cells have consistant heights above sensor in time." ;
        HEIGHT_ABOVE_SENSOR:long_name = "height_above_sensor" ;
        HEIGHT_ABOVE_SENSOR:units = "m" ;
        HEIGHT_ABOVE_SENSOR:axis = "Z" ;
        HEIGHT_ABOVE_SENSOR:positive = "up" ;
        HEIGHT_ABOVE_SENSOR:reference_datum = "sensor" ;
        HEIGHT_ABOVE_SENSOR:valid_min = -12000.f ;
        HEIGHT_ABOVE_SENSOR:valid_max = 12000.f 
```

However the first one passes the cf check while the second fails on the dimension_order test:

```
dimension_order                        :1:    82/126 : Variable VCUR has a non-
                                                      space-time dimension after
                                                      space-time-dimensions
```

And I don't think this message should output since HEIGHT_ABOVE_SENSOR is a space dimension.



Discussion:
@mhidas could you please label this issue for me (bug/imos required)?

@ggalibert Looking into this, it appears that if a variable has multiple dimensions AND a coordinates attribute that is not in T, Z, X, Y order it fails.  

I need to do some more testing to figure out the TZXY ordering for the coordinates attribute to make sure this diagnosis is 100%.

Reading the excerpt from 2.4 (included on the bottom of this comment), it appears that you can have the coordinates in a different order, as long as the the dimensions of the variable are correct.  I need to discuss with @lukecampbell  and think about the interpretation, but my gut says the test should allow for these to pass.  

```
    2.4 If any or all of the dimensions of a variable have the interpretations of "date or time" (T), "height or depth" (Z),
    "latitude" (Y), or "longitude" (X) then we recommend, those dimensions to appear in the relative order T, then Z, then Y,
    then X in the CDL definition corresponding to the file. All other dimensions should, whenever possible, be placed to the
    left of the spatiotemporal dimensions.
```

I think it should pass, it's T,Z. 

@lukecampbell Even though the coordinates at TXYZ?

oh, I see what you're saying the coordinates attribute should be

```
VCUR:coordinates = "TIME HEIGHT_ABOVE_SENSOR LATITUDE LONGITUDE" ;
```

Not 

```
VCUR:coordinates = "TIME LATITUDE LONGITUDE HEIGHT_ABOVE_SENSOR" ;
```

That's quite picky and I don't necessarily agree with CF on that one but, yeah that's right, I think.

I think this is an example of the CChecker running wild.  i dont think CF 1.6 meant to check the coordinates for 2.4  

Sound good if I fix this test to ignore the coordinates?

yes please. 

@lukecampbell I was wrong on the coordinates part, but as we discussed I have the path forward.  Will explain in PR (no time frame).


Resolving patch:
diff --git a/compliance_checker/cf/cf.py b/compliance_checker/cf/cf.py
--- a/compliance_checker/cf/cf.py
+++ b/compliance_checker/cf/cf.py
@@ -406,8 +406,11 @@ def check_dimension_order(self, ds):
             # any nones should be before classified ones
             nones    = [i for i, x in enumerate(dclass) if x is None]
             nonnones = [i for i, x in enumerate(dclass) if x is not None]
-
-            if len(nones) and len(nonnones) and max(nones) > min(nonnones):
+            '''
+            Documenting for clarification:
+            This next line of code says "If there is a non-space-time dimension and there is a space time dimension and the location of the non-space-time is before the location of the space-time dimension, fail test"
+            '''
+            if len(nones) and len(nonnones) and max(nones) < min(nonnones):
                 fails.append("Variable %s has a non-space-time dimension after space-time-dimensions"%k)
 
             # classified ones should be in correct order


Test patch: