Hello,
Note this recent R-Sig-Geo post about the "in-development" nature of the
latest builds of rgdal - you need to let us know what versions you are
using. Also, view the definition of writeGDAL() to see how the lower
level functions are used.
https://stat.ethz.ch/pipermail/r-sig-geo/2009-January/004830.html
I think your question properly belongs on R-Sig-Geo, but this might be
of interest to others here using R. Please report the results of
sessionInfo() from R. I've included an R session below using your
function, but only with a tiny input dataset.
BTW, you can simplify the writing of GTiffs with writeGDAL() -unless you
are intending to develop your function to write to the file in smaller
pieces. The code to do that can be as simple as this:
library(rgdal)
## read in matrix to bm
## . . .
## generate X/Y coordinates - assuming your matrix is aligned as image()
expects (replace 0 and 1 as needed)
xx <- seq(0, length = nrow(bm), by = 1)
yy <- seq(0, length = ncol(bm), by = 1)
##
writeGDAL(image2Grid(list(x = xx, y = yy, z = bm))
But, your R function works for me for the following simple test. As
Frank mentioned, it probably comes down to a version problem or a file
size limit (although that seems unlikely since your input matrix "bm"
must be completely loaded in memory).
library(rgdal)
#Loading required package: sp
#Geospatial Data Abstraction Library extensions to R successfully loaded
#Loaded GDAL runtime: GDAL 1.6.0, released 2008/12/04
#Path to GDAL shared files: C:\inst\R\library/rgdal/gdal
#Loaded PROJ.4 runtime: Rel. 4.6.1, 21 August 2008
#Path to PROJ.4 shared files: C:\inst\R\library/rgdal/proj
data(volcano) # matrix 87x61
bm.writeTiff(volcano, "volc.tif")
# used (Mb) gc trigger (Mb) max used (Mb)
#Ncells 305831 8.2 597831 16 407500 10.9
#Vcells 149194 1.2 786432 6 467409 3.6
tst <- readGDAL("volc.tif")
#volc.tif has GDAL driver ltalk X6
#and has 87 rows and 61 columns
I'm not at all sure what "ltalk X6" is about, also see "pt..." in the
GDALinfo() call:
> GDALinfo("volc.tif")
rows 87
columns 61
bands 1
origin.x 0
origin.y 1
res.x 1
res.y 1
oblique.x 0
oblique.y 0
driver pt...
projection NA
file volc.tif
This gives the right information, but my build of GDAL is different
from that used by rgdal.
> system("gdalinfo volc.tif")
Driver: GTiff/GeoTIFF
Files: volc.tif
Size is 61, 87
Coordinate System is `'
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 87.0)
Upper Right ( 61.0, 0.0)
Lower Right ( 61.0, 87.0)
Center ( 30.5, 43.5)
Band 1 Block=61x33 Type=Int32, ColorInterp=Gray
> system("gdalinfo --version")
GDAL 1.6.0, released 2008/12/04
sessionInfo()
R version 2.8.1 (2008-12-22)
i386-pc-mingw32
locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices datasets utils methods base
other attached packages:
[1] rgdal_0.6-1 sp_0.9-28 rcom_2.0-4 rscproxy_1.0-12
loaded via a namespace (and not attached):
[1] grid_2.8.1 lattice_0.17-17 tools_2.8.1
HTH,
Regards, Mike.
------------------------------------------------------------------------
Subject:
Re: [gdal-dev] Writing a Tiff
From:
Henning Bredel <[email protected]>
Date:
Fri, 16 Jan 2009 10:27:29 +0100
To:
Frank Warmerdam <[email protected]>
To:
Frank Warmerdam <[email protected]>
CC:
"[email protected]" <[email protected]>
On Thu, 2009-01-15 at 16:57 -0500, Frank Warmerdam wrote:
,-----------------------------------.
bm.writeTiff <- function(bm,filename) {
# GTiff ist standard but show it here, though
driver <- new('GDALDriver', 'GTiff')
t <- new("GDALTransientDataset",driver,nrow(bm),ncol(bm),
type="Int32")
for (row in 1:nrow(bm)-1) {
putRasterData(t,bm[row,1:(ncol(bm)-1)],offset=c(row,1))
}
saveDataset(t,filename)
closeDataset(t)
}
Henning,
I am embarrassed to admit I don't even know what language the above is!
Perl? Ruby?
ups .. sorry, I was on the R-sig mailinglist before, so I forget to
point the language out explicitely. It's R -- I'm using GDAL with a
wrapper package called `rgdal' (Roger Bivand is involved in its
development).
Normally there is a function to be called to register all the drivers
with the drivermanager instance. I think all the swig bindings call
this automatically at load time.
Then you could normally call GetDriverByName() in the gdal "module" however
that gets bound into your language.
Well, rgdal offers also a `getGDALDriverByName() method. The output
says that there is GeoTiff creation support.
In Python the above would be something like:
driver = gdal.GetDriverByName('GTiff')
dataset = driver.Create('file.tif', rows, columns, bands, gdal.Int32, None )
...
The main point I want to make is you don't actually create a driver object.
You just get a reference to an existing one from the driver manager which
is usually hidden by the global GetDriverByName() function
(GDALGetDriverByName() in C).
I have read a satellite image into a matrix and now I would like
to write it into an image file again (maybe this sounds strange.
If you are interested in the background, I could tell ..).
The thing is, that I want to write into another file format than
the file I have read in, so how could I get the driver, if not
creating a new one?
My first try to write a GTiff with
,--------------------------
bm.writeTiff <- function(bm,filename) {
# GTiff ist standard but show it here, though
driver <- new('GDALDriver', 'GTiff')
t <- new("GDALTransientDataset",driver,nrow(bm),ncol(bm),
type="Int32")
for (row in 1:nrow(bm)-1) {
putRasterData(t,bm[row,1:(ncol(bm)-1)],offset=c(row,1))
}
saveDataset(t,filename)
closeDataset(
`--------------------------
runs into the error (after approx. 30 sec.)
,--------------------------
Wrong "StripByteCounts" field, ignoring and calculating from imagelength
`--------------------------
What does this error mean??
Another strange thing is, that there is no GTiff support after
that error anymore! The 2nd call of `getGDALDriverNames()' out-
put is missing the GTiff entry at all. Could this be a GDAL
error or do I have to ask at the RGDAL mailinglist as well?
Thx for your help
Henning
------------------------------------------------------------------------
Subject:
Re: [gdal-dev] Writing a Tiff
From:
Frank Warmerdam <[email protected]>
Date:
Fri, 16 Jan 2009 09:17:11 -0500
To:
Henning Bredel <[email protected]>
To:
Henning Bredel <[email protected]>
CC:
"[email protected]" <[email protected]>
Henning Bredel wrote:
ups .. sorry, I was on the R-sig mailinglist before, so I forget to
point the language out explicitely. It's R -- I'm using GDAL with a
wrapper package called `rgdal' (Roger Bivand is involved in its
development).
Henning,
Gotcha.
I will note that the R bindings are not generated using SWIG so some
of my assumptions in the previous email can be wrong.
runs into the error (after approx. 30 sec.)
,--------------------------
Wrong "StripByteCounts" field, ignoring and calculating from
imagelength
`--------------------------
What does this error mean??
Another strange thing is, that there is no GTiff support after
that error anymore! The 2nd call of `getGDALDriverNames()' out-
put is missing the GTiff entry at all. Could this be a GDAL error or
do I have to ask at the RGDAL mailinglist as well?
My guess is that there has been some sort of heap corruption.
Normally you would only get the "Wrong StripByteCounts" message when
reading
a poorly generated TIFF file from an underlying library other than
libtiff.
If you are getting it while operating on a TIFF file being generated with
libtiff (and GDAL) it likely means that the file was corrupted or that
the heap was somehow corrupted. There could be quite a number of
possible
reasons for this.
I will note that the GDAL geotiff writer in some cases stresses the
limits
of libtiff and it can be important to have a very recent version (such as
the CVS head from the libtiff repository). The version included with
GDAL
internally is generally suitable. Versions of libtiff provided with
software distributions are generally somewhat antique.
Nevertheless, your simple write through case is not a complicated one and
would not normally trigger problems.
Is it possible your TIFF file is growing to be larger than 4GB? If you
are using an older non-BigTIFF version of libtiff this could cause
issues.
Recent versions of GDAL will generally warn if this is likely to be a
problem
but I don't recall your quoting the GDAL version number.
Best regards,
------------------------------------------------------------------------
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.10.8/1898 - Release Date: 16/01/2009 3:09 PM
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
