| 96 | | When exporting rasters to NetCDF, save Coordinate Variables for the projected SRS, as required by the CF-1 convention, normally saved as "x" and "y". |
| 97 | | |
| 98 | | Optionally using -co options listed above, also write 2D 'lat' and 'lon' arrays, which are specified as part of the CF-1 convention for map projections - but are not actually required for the Unidata-maintained NetCDF Java API and applications built upon them (eg ncWMS, Thredds Data Server). |
| | 96 | When exporting rasters to NetCDF, save Coordinate Variables for the projected SRS, as required by the CF-1 convention, normally saved with names "x" and "y" (these are the names for every CF-1 projection except Rotated Pole - see CF-1 App F linked above for details). |
| | 97 | |
| | 98 | We have also added a '-co' driver option listed above, that allows specification to also write 2D 'lat' and 'lon' arrays, which are specified as part of the CF-1 convention for map projections - but are not actually required for the Unidata-maintained NetCDF Java API and applications built upon them (eg ncWMS, Thredds Data Server). |
| 104 | | The CF-1 conventions specify these coordinate variables as necessary for grids, see [[http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/ch05s06.html ch5.6]] and [[http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/apf.html App F]] in the document. |
| 105 | | |
| 106 | | Tests with NetCDF CF-1 reading software indeed show that rasters with projected grids will not be correctly interpreted without the coordinate variables in the projected system (the NetCDF-Java API determines this, since it's used by ncWMS, ToolsUI and Thredds Data Server). |
| 107 | | |
| 108 | | While the CF-1 convention examples also contain 2D "lat" and "lon" Variables containing the latitude and longitude at each data point, tests have shown that the NetCDF Java API can correctly interpret CF-1 data without these added. The rationale for this point is given at http://www.mail-archive.com/cf-metadata@cgd.ucar.edu/msg00759.html. |
| 109 | | |
| 110 | | Thus we've chosen to make it ''optional'' to write these Variables, as they are redundant from GDAL's point of view (Lat and Lon are calculated on-the-fly), and they increase the size of a NetCDF file significantly. (E.g. if the actual band-data is stored as a 2D Byte array, but the lat and lon are stored as doubles, then the file-size can easily increase by 10X). |
| | 104 | The CF-1 conventions specify the X and Y projected coordinate variables as necessary to define projected grids, and tests with common NetCDF CF-1 reading software indeed show that rasters with projected grids will not be correctly interpreted without them (the NetCDF-Java API determines this, since it's used by ncWMS, ToolsUI and Thredds Data Server). |
| | 105 | |
| | 106 | While the CF-1 convention also formally requires 2D "lat" and "lon" Variables containing the latitude and longitude at each data point, these are redundant in the case of software that can read the encoded projection and perform conversion to Geographic calculation on the fly. They also add very significantly to file-size of the saved raster since they are 2D arrays and saved as double/float. Thus the NetCDF Java API chose not to require their presence and can correctly project NetCDF files that contain just the X and Y coordinate variables (see [[http://www.mail-archive.com/cf-metadata@cgd.ucar.edu/msg00759.html this mailing list post by NetCDF Java]] explaining this decision). |
| | 107 | |
| | 108 | Thus we've chosen to make it ''optional'' to write these Variables - but provide the 'WRITE_LONLAT' co option for users who wish to make sure their data is fully self-describing and CF-1 compliant, without relying on on-the-fly reprojection. |
