SpatialGridDataFrame to netcdf grid

Windows or Linux?  My experience is in Windows.  I would writeGDAL() the
SGDF to GTiff, then use gdal_translate at the command line to convert to
netCDF:

gdal_translate -of NetCDF in.tif out.nc

On Mon, 12 Nov 2007 13:38:57 +1100,
Michael Sumner <mdsumner at utas.edu.au> wrote:

  

Windows or Linux?  My experience is in Windows.  I would writeGDAL() the
SGDF to GTiff, then use gdal_translate at the command line to convert to
netCDF:
    

gdal_translate -of NetCDF in.tif out.nc
    

Thanks for the idea, I'm under GNU/Linux though and don't see that
command.  It may not be difficult to track down the equivalent though.  At
any rate, is there some tradeoff to consider when using this these SGDF ->
GTiff -> NetCDF conversions?  I may have to look deeper into the other
packages (e.g. RNetCDF as you mentioned).

All the best,

On linux, you should have the netCDF driver istalled; from gdalDrivers()
I see (on debian etch):

        name long_name create copy 42 netCDF Network Common Data Format
FALSE TRUE

Then, reading the documentation of writeGDAL:

     'create2GDAL' creates a GDAL data set from a SpatialGridDataFrame
object, in particular to be able to save to GDAL driver formats that
only permit copying rather than creation.

Which is the case for net netCDF format. Might work!

On Mon, 12 Nov 2007 08:56:30 +0100,
"Edzer J. Pebesma" <edzer.pebesma at uni-muenster.de> wrote:

On linux, you should have the netCDF driver istalled; from gdalDrivers()
I see (on debian etch):

        name long_name create copy 42 netCDF Network Common Data Format
FALSE TRUE

Then, reading the documentation of writeGDAL:

     'create2GDAL' creates a GDAL data set from a SpatialGridDataFrame
object, in particular to be able to save to GDAL driver formats that
only permit copying rather than creation.

Which is the case for net netCDF format. Might work!

Thank you, I also see the same output in gdalDrivers():

       name                               long_name create  copy
43    netCDF              Network Common Data Format  FALSE  TRUE


but then create2GDAL fails with:

R> create2GDAL(locs.sub.ts, drivername="netCDF")
Error in .local(.Object, ...) :

	GDAL Error 6: GDALDriver::Create() ... no create method implemented for this format.

I don't understand this message, given that create2GDAL() should be used
when only copying is allowed for a driver (as reported by gdalDrivers(),
and ?writeGDAL).  I'm using:

---<---------------cut here---------------start-------------->---
R> sessionInfo()
R version 2.6.0 (2007-10-03)
x86_64-pc-linux-gnu

locale:
LC_CTYPE=en_CA.UTF-8;LC_NUMERIC=C;LC_TIME=en_CA.UTF-8;LC_COLLATE=en_CA.UTF-8;LC_MONETARY=en_CA.UTF-8;LC_MESSAGES=en_CA.UTF-8;LC_PAPER=en_CA.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_CA.UTF-8;LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] RColorBrewer_1.0-2 maptools_0.6-19    foreign_0.8-23     trip_1.0-4
[5] rgdal_0.5-20       sp_0.9-17          gstat_0.9-40       maps_2.0-38
[9] rcompgen_0.1-17    lattice_0.17-2

loaded via a namespace (and not attached):
[1] grid_2.6.0  tools_2.6.0
---<---------------cut here---------------end---------------->---

No, see the example in the help file. Use this function to create a
dataset that can be created:

xx <- create2GDAL(locs.sub.ts, drivername="GTiff")

then copy xx:

xxx <- copyDataset(xx, drivername="netCDF")

On Mon, 12 Nov 2007 22:21:08 +0100 (CET),
Roger Bivand <Roger.Bivand at nhh.no> wrote:

[...]

No, see the example in the help file. Use this function to create a
dataset that can be created:

xx <- create2GDAL(locs.sub.ts, drivername="GTiff")

then copy xx:

xxx <- copyDataset(xx, drivername="netCDF")

Thanks Roger, I understand the process a little better.  However, R simply
crashes at this copying stage with:

---<---------------cut here---------------start-------------->---
netcdf: 4 is not a valid cdfid

Process R exited abnormally with code 3 at Mon Nov 12 16:00:27 2007
---<---------------cut here---------------end---------------->---

without leaving any other trace.  It seems as if this is an issue with
gdal netcdf driver.  Googling turns up a couple of hits with this message,
but they all indicate the problem should already be fixed with the current
version of gdal in Debian unstable (the system this happens on).

Then the fallback is to write a GTiff, and use gdal_translate to convert
it (one of the gdal utilities that build with the GDAL shared
object). If the same problem occurs, you may need to install netCDF and
GDAL from source. If that doesn't resolve it, then you'll need to
reshape the data to the required format and use functions in the ncdf
package to create and write to the file.

On Mon, 12 Nov 2007 23:29:59 +0100 (CET),
Roger Bivand <Roger.Bivand at nhh.no> wrote:

[...]

  

Then the fallback is to write a GTiff, and use gdal_translate to convert
it (one of the gdal utilities that build with the GDAL shared
object). If the same problem occurs, you may need to install netCDF and
GDAL from source. If that doesn't resolve it, then you'll need to
reshape the data to the required format and use functions in the ncdf
package to create and write to the file.
    

I found out that the Debian packages with the gdal_translate binary is
gdal-bin, and trying to writeGDAL() to GTiff and then gdal_translate as
suggested earlier gives the same error message about cdfid not being
valid.

Just so I understand how the SpatialGridDataFrame object is structured:

R> gridparameters(locs.sub.ts)
  cellcentre.offset cellsize cells.dim
1            -69.12  0.06109       113
2             63.64  0.03424       122
R> bbox(locs.sub.ts)
             min    max
coords.x1 -69.15 -62.25
coords.x2  63.62  67.80

How are the data (e.g. z values) aligned with respect to these values?  I
would like to know what as.data.frame(locs.sub.ts) returns: the
coordinates and data for the midpoint of the cell, or the data for some
other reference point in the cell.  Thanks again for any help.