Changes between Version 37 and Version 38 of NetCDF_exportUpdateChanges


Ignore:
Timestamp:
Oct 13, 2011, 8:33:45 PM (13 years ago)
Author:
pds
Comment:

Added reference to Github repo

Legend:

Unmodified
Added
Removed
Modified

  • NetCDF_exportUpdateChanges

    v37 v38  
    110110==== 3.2) Proj. SRS Handling: Add saving of reference Ellipsoid parameters in CF-1 compliant format used by dataset ====
    111111
    112 '''Related fix''': #2893 [[BR]]
    113112'''New -co options''': No, though related to the new proposed WRITE_GDAL_TAGS option above.
    114113
    … …  
    130129'''Rationale''':
    131130
    132 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'.
    133 
    134 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.
    135 
    136 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.
     131CF-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
     133In 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.
    137134
    138135==== 3.3) Proj. SRS Handling: Continue saving GDAL custom attribute tags by default to CRS definition, but add option not to save ====
    139136
    140 '''Related fix''': N/A [[BR]]
    141137'''New -co options''': -co WRITE_GDAL_TAGS (yes/no, defaults to yes)[[BR]]
    142138'''Has back-compat impact?''': No
    … …  
    144140'''Change''':
    145141
    146 In addition to following the CF-1 conventions to save projection metadata, the NetCDF driver writes metadata in several custom attributes:
     142In addition to following the CF-1 conventions to save projection metadata, the current NetCDF driver writes metadata in several custom attributes:
    147143 * A "spatial_ref" tag containing full OGC WKT string, including datum and EPSG codes if known.
    148144 * A geotransform array saved as a string (GeoTransform),
    149145 * and individual corner coordinates (NN, SS, WE and WW).
    150146
    151 The new WRITE_GDAL_TAGS driver creation option allows the user to choose not to write these tags. However it would be set to 'YES' by default.
    152 
    153 The new implementation saves the GeoTransform array only if the lon/lat or x/y values are not written to the file, and the corner coordinates are never saved as they are redundant.
    154 
    155 **PDS comment**: do you mean just "lon/lat" above? As that's what it looks like in the code. And the new driver always saves X/Y right?
     147We propose adding a new WRITE_GDAL_TAGS driver creation option to allow the user to choose not to write these tags. However it would be set to 'YES' by default.
     148
     149A 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?
    156152
    157153{{{
    158154#!comment
     155
     156PDS: Removing this as we considered not crucial/not clearly the right way to go.
     157
    159158Note: when importing files in NetCDF format, the driver checks the GDAL-written WKT matches the projection information stored in the CF-compliant attributes. If there is a conflict, the CF-compliant CRS will be considered as authoritative.
    160159}}}
    … …  
    162161'''Rationale''':
    163162
    164 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. Currently, the CF-1 convention doesn't allow saving all the projection information that GDAL can manipulate via a WKT (such as named Datums, and EPSG authorities).
    165 
    166 However, there is certainly 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.
    167 
    168 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 .
    169 
     163We 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
     165The 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.
    170166
    171167=== 4) Add support for different netcdf file types and compression ===
    … …  
    197193
    198194 * The code will be committed to the trunk, and if possible will be back-ported to the 1.8 series (should a 1.8.2 release occur after implementation and sufficient testing).
     195   * Since the modifications above involved a lot of related changes to significant parts of the driver, we managed the actual development process using a Github repository for integration and testing.
     196   * The address of the Github repo, if you wish to view the code or do testing, is at https://github.com/etiennesky/gdal-netcdf/
    199197 * We will ask to the users of the driver to please test the new version with their important files and notify any regressions.
    200  * As there are many issues (most of which are in the trac database) and the modification to the code are relatively important, it would be much easier to apply the changes in one massive commit.
    201 
    202 ** PDS Comment: Not sure this last bullet point needed? If you're going to keep it, you may need to explain the context of using a Github repository to manage NetCDF changes as a sub-project. **
     198
    203199== Addenda ==
    204200