Changes between Version 13 and Version 14 of NetCDF_exportUpdateChanges
- Timestamp:
- Sep 25, 2011, 8:08:21 AM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
NetCDF_exportUpdateChanges
v13 v14 2 2 3 3 (Note: this is an initial draft by pds - to collect related ideas for input and if necessary RFC development) 4 5 (Note from Etienne, I have added some comments starting with -> ) 4 6 5 7 Status: Development … … 7 9 == Summary == 8 10 9 In August 2011 Etienne Touri nsky initiated a discussion on the GDAL mailing list proposing and calling for interest in improvements to GDAL's NetCDF driver (Subject: discussion on improvements to the NetCDF driver and CF-1 convention), and collected ideas at wiki:NetCDF_Improvements.11 In August 2011 Etienne Tourigny initiated a discussion on the GDAL mailing list proposing and calling for interest in improvements to GDAL's NetCDF driver (Subject: discussion on improvements to the NetCDF driver and CF-1 convention), and collected ideas at wiki:NetCDF_Improvements. 10 12 11 This page summarises several of the proposed improvements that would improve the compatibility of GDAL's NetCDF driver with the CF-1 NetCDF conventions :- but change the default behaviour of the driver and thus affect backward compatibility.13 This page summarises several of the proposed changes that would improve the compatibility of GDAL's NetCDF driver with the CF-1 NetCDF conventions :- but change the default behaviour of the driver and thus affect backward compatibility. 12 14 13 15 The changes affect orientation of data, handling of datum parameters, writing coordinate variables, and are described specifically below. … … 31 33 '''New -co options''': ?? Should we include an option to allow force assume south-regular? 32 34 35 -> I don`t think so! 36 33 37 '''Has back-compat impact?''': Yes - since affects default import and export NetCDF behaviour. 38 39 -> try to open a file with gdalinfo (version 1.8.1) and see if the bounds are ok, I think they should be ok, in which case there is no back-wards compatibility issue 40 41 here is where upside-down is checked 42 {{{ 43 // Check for reverse order of y-coordinate 44 if ( yMinMax[0] > yMinMax[1] ) { 45 dummy[0] = yMinMax[1]; 46 dummy[1] = yMinMax[0]; 47 yMinMax[0] = dummy[0]; 48 yMinMax[1] = dummy[1]; 49 } 50 }}} 51 -> Try to create the file with and without custom gdal tags and see if both work. thanks 34 52 35 53 '''Change''': … … 55 73 * A geotransform array, saved as a string (!GeoTransform). 56 74 75 -> added a new proj4 string 76 57 77 The WRITEGDALTAGS driver creation option would allow the user to choose not to write these tags. However it would be set to 'YES' by default. 58 78 … … 77 97 78 98 ((?? 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?)) 99 100 -> we could look into that for most common datums, but specify that there is no guarantee that a specific datum will be checked for. 79 101 80 102 '''Rationale''':
