[gdal-dev] Writing a Tiff
Michael Sumner
mdsumner at utas.edu.au
Mon Jan 19 04:57:45 EST 2009
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 <henning.bredel at uni-muenster.de>
> Date:
> Fri, 16 Jan 2009 10:27:29 +0100
> To:
> Frank Warmerdam <warmerdam at pobox.com>
>
> To:
> Frank Warmerdam <warmerdam at pobox.com>
> CC:
> "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
>
>
> 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 <warmerdam at pobox.com>
> Date:
> Fri, 16 Jan 2009 09:17:11 -0500
> To:
> Henning Bredel <henning.bredel at uni-muenster.de>
>
> To:
> Henning Bredel <henning.bredel at uni-muenster.de>
> CC:
> "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
>
>
> 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
> gdal-dev at lists.osgeo.org
> 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
>
>
More information about the gdal-dev
mailing list