Changes between Version 27 and Version 28 of NetCDF_exportUpdateChanges

Timestamp:

Oct 12, 2011, 10:18:19 PM (13 years ago)

Author:

pds

Comment:

--

NetCDF_exportUpdateChanges

@@ -87 +87 @@
 Note: In the longer-term we would view it as advantageous that the CF-1 conventions were augmented to allow recording of full datum information, and reduce the need to store extra CRS information in GDAL-managed attributes. However this will require agreement of the CF-1 community for a new standard, and would take time to agree upon and adopt.  See https://cf-pcmdi.llnl.gov/trac/ticket/69 .
 
-=== Add saving of Datum reference Ellipsoid parameters in CF-1 compliant format, in addition to within GDAL's WKT ===
+=== SRS Handling: Add saving of reference Ellipsoid parameters in CF-1 compliant format used by dataset ===
 
 '''Related fix''': #2893 [[BR]]
@@ -96 +96 @@
 '''Change''':
 
-When exporting to NetCDF, save CF-1 attributes that specify the reference ellipsoid used by the projection SRS's datum. Continue also saving this information in the special GDAL "spatial_ref" tag.
+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').
 
-Note: when importing, the GDAL WKT datum information would be checked first as it fully specifies the datum. The CF-1 ellipsoid information would be usable as a fall-back.
+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.
 
+{{{
+#!comment
 ((?? 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?))
 
--> we could look into that for most common datums, but specify that there is no guarantee that a specific datum will be checked for.
+-> 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.
+}}}
 
 '''Rationale''':