54 | | '''Related fix''': #4251[[BR]] |
55 | | |
56 | | '''New -co options''': No |
57 | | |
58 | | '''Has back-compat impact?''': Only for GDAL versions prior to 1.6 (r18152). Since then, a check is made to ensure the driver recognizes bottom-up grids and flips the y-axis accordingly. |
59 | | |
60 | | '''Change''': |
61 | | |
62 | | When GDAL exports to NetCDF, translate the data so that it is in "south up" orientation, i.e. invert the data from the GDAL default. Import is not changed as it is already compatible. |
| 54 | '''Related fix''': #4284 [[BR]] |
| 55 | |
| 56 | '''New ConfigOptions''': GDAL_NETCDF_BOTTOMUP=YES/NO, default YES, for default export and import |
| 57 | |
| 58 | '''New -co options''': WRITE_BOTTOMUP=YES/NO, default YES, for default export |
| 59 | |
| 60 | '''Has back-compat impact?''': Only for GDAL versions prior to 1.6 (r18152). Since then, a check is made to ensure the driver recognizes bottom-up grids (using the CF tags) and flips the y-axis accordingly. An exception is when there is not geo-referencing data, in which case it may be in the wrong direction. The export options can be used to force top-down if needed. |
| 61 | |
| 62 | '''Change''': |
| 63 | |
| 64 | When GDAL exports to NetCDF, translate the data so that it is in "south up" orientation, i.e. invert the data from the GDAL default. Import and export assume bottom-up, but import and export options can change the default. Import of files created by earlier versions of the driver assume top-down for backwards compatibility. When there is information on the orientation from CF Y axis values, default values are overridden. |
110 | | ==== 3.2) Proj. SRS Handling: Add saving of reference Ellipsoid parameters in CF-1 compliant format used by dataset ==== |
111 | | |
112 | | '''New -co options''': No, though related to the new proposed WRITE_GDAL_TAGS option above. |
113 | | |
114 | | '''Has back-compat impact?''': No |
115 | | |
116 | | '''Change''': |
117 | | |
118 | | When exporting to NetCDF, the new driver will utilise the CF-1 attributes that allow specification of the reference ellipsoid used by the dataset's CRS (e.g. 'semi_major_axis', 'inverse_flattening'). |
119 | | |
120 | | However, on importing data the driver will continue to use the full GDAL WKT specification in the 'spatial_ref' attribute where present. This is because the CF-1.5 conventions still don't include provision for saving full Datum information, such as the name and authority of the datum, which is needed for precise transformations. The CF-1 ellipsoid attributes will only be used as a fallback when the full WKT isn't present. |
121 | | |
122 | | {{{ |
123 | | #!comment |
124 | | ((?? pds: Should we add anything here about special import behaviour, e.g. whether to auto-detect datum on import based on ellipsoid values?? Or should there be an option for this?)) |
125 | | |
126 | | -> etienne: we could look into that for most common datums, but specify that there is no guarantee that a specific datum will be checked for. |
127 | | }}} |
128 | | |
129 | | '''Rationale''': |
130 | | |
131 | | CF-1 convention's only support of datums currently is to specify a reference ellipsoid using parameters such as 'semi_major_axis' and 'inverse_flattening'. While these attributes alone do not fully specify the datum (which requires an EPSG code so control points can be referenced), they at least allow fairly accurate map projection of the created NetCDF file using tools such as ncWMS. |
132 | | |
133 | | In the longer-term it would be beneficial to work with the CF-1 community to allow saving of full datum information in a format readable by CF-1, and we've made preliminary enquiries here and would welcome cooperation with the CF-1 community, but updating the CF-1 standard is outside the scope of this current GDAL NetCDF work. |
134 | | |
135 | | ==== 3.3) Proj. SRS Handling: Continue saving GDAL custom attribute tags by default to CRS definition, but add option not to save ==== |
| 112 | ==== 3.2) Proj. SRS Handling: Continue saving GDAL custom attribute tags in addition to CRS definition, but add option not to save ==== |
149 | | A further refinement in the new driver is that the new implementation saves the GeoTransform array only if the lon/lat values are not written to the file, and the corner coordinates are never saved as they are redundant. |
150 | | |
151 | | **PDS comment**: I edited the above sentence to remove "X/Y" that was with "lon/lat" above? As that's what it looks like in the code. And the new driver always saves X/Y right? |
| 128 | When importing files in NetCDF format, the driver checks the GDAL-written WKT (including Datum) matches the projection information stored in the CF-compliant attributes. If there is a conflict, the CF-compliant CRS will be considered as authoritative. |
| 129 | |
| 130 | '''Rationale''': |
| 131 | |
| 132 | We assume by default that if users export to a NetCDF file from GDAL, then they may wish to import into GDAL again and retain full information. As stated above, the CF-1 convention doesn't allow saving all the projection information that GDAL can manipulate via a WKT, so we recommend keeping current behaviour by default to allow lossless re-import into GDAL. The 'extra' attributes do not interfere with the ability of CF-1 compliant tools such as NetCDF-Java to open and update rasters. |
| 133 | |
| 134 | The extra option to not save GDAL tags has been added in recognition of a use-case to export to a NetCDF file with no intention to access again via GDAL and use purely for use by CF-1 applications, in which case the user may wish to have no additional metadata present. |
| 135 | |
| 136 | The GeoTranform array is not written to file unless there is no means to recover that information (i.e. in the case when lon/lat values are not written to file for a geographic CRS). |
| 137 | |
| 138 | ==== 3.3) Proj. SRS Handling: Add saving of reference Ellipsoid parameters in CF-1 compliant format used by dataset ==== |
| 139 | |
| 140 | '''New -co options''': No, though related to the new proposed WRITE_GDAL_TAGS option below. |
| 141 | |
| 142 | '''Has back-compat impact?''': No |
| 143 | |
| 144 | '''Change''': |
| 145 | |
| 146 | When exporting to NetCDF, the new driver will utilise the CF-1 attributes that allow specification of the reference ellipsoid used by the dataset's CRS (e.g. 'semi_major_axis', 'inverse_flattening', 'longitude_of_prime_meridian'). |
| 147 | |
| 148 | However, on importing data the driver will continue to use the full GDAL WKT specification in the 'spatial_ref' attribute where present (as described in 3.2). This is because the CF-1.5 conventions still don't include provision for saving full Datum information, such as the name and authority of the datum, which is needed for precise transformations. The CF-1 ellipsoid attributes will only be used as a fallback when the full WKT isn't present. |
161 | | '''Rationale''': |
162 | | |
163 | | We assume by default that if users export to a NetCDF file from GDAL, then they may wish to import into GDAL again and retain full information. As stated above, the CF-1 convention doesn't allow saving all the projection information that GDAL can manipulate via a WKT, so we recommend keeping current behaviour by default to allow lossless re-import into GDAL. The 'extra' attributes do not interfere with the ability of CF-1 compliant tools such as NetCDF-Java to open and update rasters. |
164 | | |
165 | | The extra option to not save GDAL tags has been added in recognition of a use-case to export to a NetCDF file with no intention to access again via GDAL and use purely for use by CF-1 applications, in which case the user may wish to have no additional metadata present. |
| 158 | '''Rationale''': |
| 159 | |
| 160 | CF-1 convention's only support of datums currently is to specify a reference ellipsoid using parameters such as 'semi_major_axis' and 'inverse_flattening'. While these attributes alone do not fully specify the datum (which requires an EPSG code so control points can be referenced), they at least allow fairly accurate map projection of the created NetCDF file using tools such as ncWMS. |
| 161 | |
| 162 | In the longer-term it would be beneficial to work with the CF-1 community to allow saving of full datum information in a format readable by CF-1, and we've made preliminary enquiries here and would welcome cooperation with the CF-1 community, but updating the CF-1 standard is outside the scope of this current GDAL NetCDF work. |
| 163 | |