@snowman2 @dblodgett-usgs @JonathanGregory Second what Dave says. The argument seems to be to break everything in the CF world so that GDAL will work better with netcdf files. Why not improve GDAL (supposedly based on a talk I heard the new, I believe yet to be released version indeed does have better support).
GDAL is a great library and a lot of work has gone into it, but its netcdf support has always been sketchy . When I first was directed to it years ago, it could only do 2-D files, and would flip the data, even when the metadata clearly said the axes went in the other direction (it just ignored the metadata attributes). That problem lasted for a long time (for all I know it still does this). GDAL has had problems with greater than 3-D files, forecast files, DSG files, files that are part of the NCEI examples for sending in data, some issues with time, and some of the newer features in netcdf4 files. Things that can improve CF are most welcome, things that would potentially break most present CF based software should have to make an awfully strong case for the benefits. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-569380308 This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
