Fwd: [gdal-dev] Re: discussion on improvements to the NetCDF
driver and CF-1 convention
Patrick Sunter
patdevelop at gmail.com
Wed Aug 31 20:30:23 EDT 2011
> Message: 6
> Date: Wed, 31 Aug 2011 13:05:11 -0700 (PDT)
> From: Etienne Tourigny <etiennesky at yahoo.com>
> Subject: Re: Fwd: [gdal-dev] Re: discussion on improvements to the
> NetCDF driver and CF-1 convention
> To: Hendy Sumanto <hsumanto at vpac.org>, "gdal-dev at lists.osgeo.org"
> <gdal-dev at lists.osgeo.org>
> Message-ID:
> <1314821111.88515.YahooMailNeo at web36903.mail.mud.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hendy
>
> 1)
>
>
> I added an item on the wiki page under I/O issues, can you make a detailed ticket and link to it on the wiki?
>
>
>
> In the mean time, please use Even's suggestion of using an intermediary format such as VRT.
>
> * Support Create() method so that gdalwarp can be used on a netcdf file
>
Hi Etienne,
I work for the same organisation as Hendy and have also been looking
at NetCDF issues, and have been looking at feasibility of supporting a
Create() method for NetCDF in particular. So I created a new ticket
(#4221) about this, and updated the NetCDF improvements wiki page to
link to it as suggested.
A couple of comments based on my study of the driver tutorial and code
below ....
> It's not as simple as it may seem, because all modifications to the netcdf file (not internal gdal information) are done only in the CreateCopy() function. in Create() you don't have information on geotransform and projection, nor raster bands.
Hmm - looking at the signature for Create() on the tutorial page
(http://www.gdal.org/gdal_drivertut.html#gdal_drivertut_creation_create)
you do at least seem to get the # of bands and size of the raster. So
you could declare empty NetCDF Variables as required, then come back
and add projection information as a variable later.
I know with NetCDF classic there are some potential performance issues
with adding variables to an already existing file (See
http://www.unidata.ucar.edu/software/netcdf/workshops/most-recent/classic_perf/FileFormat.html)
- but there also seem ways around this of adding extra space
beforehand.
So this seems positive (though I'm no gdal expert yet ;)).
> A flag could indicate if projection/geotransform need to be written after it has been changed. To avoid code de-duplication, the code in NCDFCreateCopy() related to projection/geotransform could be moved to a new function like SetNetcdfDimensions(). The RasterIO issues that Even mentioned can also be challenging.
>
Agreed, it looks like refactoring the existing CreateCopy() method so
common functionality was available to both would be the way to go.
cheers, Patrick.
>
> 2)
>
> I assume your file is in a projected CRS?In any case, the current implementation is not 100% CF compliant. GDAL can read them (through custom tags), but other software cannot. I have submitted a patch to fix geographic CRS only.
>
> Please add this information to existing bug #2893 (which I have renamed tonetcdf driver does not read and write CF-1.0 coordinate system properly for projected CRS), along with your file (which was stripped by the mailing list)
>
> BTW, there is a nifty CF compliance checker (python script and online checker) which I have added to the wiki. Please test your file with it. It's possible that lambert_conformal_conic:standard_parallel_1 is valid CF, it needs to be tested.
>
>
> Regards,
> Etienne
>
>
>
>
> ----- Original Message -----
> From: Hendy Sumanto <hsumanto at vpac.org>
> To: gdal-dev at lists.osgeo.org
> Cc:
> Sent: Wednesday, August 31, 2011 1:23:54 AM
> Subject: Fwd: [gdal-dev] Re: discussion on improvements to the NetCDF driver and CF-1 convention
>
> Hi Etienne,
>
> I have a few items which I would like to put as new topics in the wiki entry but I think I better describe them here first before putting any entry or creating tickets.
>
> 1. As part of the improvement to the NetCDF driver, is it possible to make request to implement the Create method for the driver so that tool such as gdalwarp can output as NetCDF output.
>
> 2. Recently I was trying to serve the NetCDF dataset (which were created by gdal_translate geotiff LANDSAT dataset into NetCDF)
> using THREDDS data server. When I try to access it via WMS using viewer such as Godiva2, I was not able to view the dataset correctly.
>
> When I used the netCDF toolsUI to check the NetCDF dataset, it is not recognized as a grid by NetCDF Tools (4.2).
>
> Looking at this documentation (http://www.unidata.ucar.edu/software/netcdf-java/reference/StandardCoordinateTransforms.html),
> in order for grid data to be viewable, the NetCDF dataset must:
> a) define x and y projection coordinate variables, using the correct projection units, typically km on the projection plane.
> b) define your projection dummy variable which has an attribute "grid_mapping_name"
> c) refer to the projection in your data variables with the "grid_mapping" attribute.
>
> Checking on the GDAL netCDF, it only define x and y dimensions but not x and y projection coordinate variables (point a is not followed).
>
> Thus, I wondering whether other people have experienced the same issue as what I am having.
>
> Then I just tried to:
> -generate its CDL by ncdump the GDAL netCDF file into CDL
> -and the define x and y projection coordinate variables (as shown below) into the CDL
> double y(y) ;
> y:units = "m" ;
> y:standard_name = "projection_y_coordinate" ;
> y:long_name = "y coordinate of projection" ;
> double x(x) ;
> x:units = "m" ;
> x:standard_name = "projection_x_coordinate" ;
> x:long_name = "x coordinate of projection" ;
> -regenerate the netCDF file from the modified CDL using ncgen
> -populate the y coordinate variable in the NetCDF file with
> ymin, ymin+resolution, ymin+2*resolution, ...
> -populate the x coordinate variable with
> xmin, xmin+resolution, xmin+2*resolution, ...
> -if I then serve the modified NetCDF dataset again using THREDDS data server, now it can be viewed correctly.
>
> Note: xmin, ymin are the lower left corner and resolution is the raster pixel size.
>
> Thus, my questions:
> i)Is there a specific reason why the current driver do not define the x and y projection coordinate variables but only defining x and y dimensions.
> For the dataset to be viewable using tools such as netCDF toolsUI or when the dataset are served via THREDDS dataset, we might have to add projection coordinate variables and the correct values
> into the netCDF file.
> ii)For lambert conformal conic projection with more than one standard parallel values, GDAL netCDF file is showing
> lambert_conformal_conic:standard_parallel_1 = -18.f ;
> lambert_conformal_conic:standard_parallel_2 = -36.f ;
> but the correct one (for the dataset to be viewable using toolsUI or THREDDS) should be
> lambert_conformal_conic:standard_parallel = -18.f,-36.f ;
>
> Could you please please comment on 1, 2(i) and 2(ii)?
>
> The attached files:
> tile.nc - GDAL netCDF file
> tile-fixed-new.nc - the one I just tried to fix and can be viewed in netCDF toolsUI or served in THREDDS
>
> Regards,
>
> Hendy
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> ------------------------------
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> End of gdal-dev Digest, Vol 88, Issue 1
> ***************************************
>
More information about the gdal-dev
mailing list