Surface point DSG needs a Z coordinate variable?
Opened this issue · 5 comments
When I open this DSG file in PyFerret I get a response that indicates it cannot be interpreted as a DSG because "Required coordinate variables not found. Point file is missing directions: vert". Seems like a point data set defined on lat/lon/time would be just fine. Is there something else wrong with this DSG file? Or is this something than can be fixed in PyFerret.
I used the current dev version of PyFerret.
PyFerret v7.64 (optimized)
Linux 5.8.0-1041-azure - 09/23/2
Technically both Point and Trajectory datasets should have a depth or altitude coordinate variable. But we don't require that for trajectory datasets - because lots of the SOCAT datasets didn't have a depth coordinate, and Point data should be handled the same way.
I had noticed this late last fall when looking at revising some of the demo scripts that are part of the PyFerret distribution (which I have not finished or checked in).
There's already an update in https://github.com/NOAA-PMEL/PyFerret/blob/master/fmt/src/cd_dsg_scan_vars.F which takes care of this.
Ok. Glad there appears to be a fix already set to be applied. This made me curious and so I checked and for what it's worth, the IOOS CF Compliance checker at [https://compliance.ioos.us/index.html] give this file a 100% clean bill of health for CF Conventions 1.6 so I think it would be good to have PyFerret understand it as a DSG even if there is some wiggle room in the conversions interpretation.
IOOS Compliance Checker Report
Version 5.0.0
Report generated 2022-02-07T15:36:44Z
cf:1.6
http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html
All tests passed!
Just an FYI here. Out of curiosity, I created some small files based on datasets that are used by the PyFerret benchmark suite, but I removed some of the coordinate variables. The IOOS compliance checker, checking against CF 1.6, recommends additional attributes for these files but does not complain at all about missing coordinates - point data with no x-y coordinates, trajectory data without x-y coordinates, timeseries data without a time coordinate variable, etc. So it seems that existence of coordinate variables just isn't part of their tests.
The checker at http://pumatest.nerc.ac.uk/cgi-bin/cf-checker.pl behaves similarly, with the report focusing just on attributes.
Here are my test files,
dsg_coord_tests.tar.gz
To the main point, it does impossible for a timeseries data set to be defined on a "discrete geometry" without having a coordinate for XYZ and T. But apparently such data sets exist in the wild with XY and T, but no Z. So if we plot them as if they are on the surface that might be useful to folks using LAS.
Agreed. The current implementation does work this way for timeseries and trajectory datasets; allowing us to work with ones which don't include a vertical coordinate. Plots simply don't include a note about the vertical, just as when working with a gridded dataset in XYT where plots have no label about the z dimension. That accommodation had been missed for point-type dsg datasets.