Re: [gdal-dev] Writing a Tiff
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 7864326 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)
rows87
columns 61
bands 1
origin.x0
origin.y1
res.x 1
res.y 1
oblique.x 0
oblique.y 0
driver pt...
projection NA
filevolc.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.bre...@uni-muenster.de
Date:
Fri, 16 Jan 2009 10:27:29 +0100
To:
Frank Warmerdam warmer...@pobox.com
To:
Frank Warmerdam warmer...@pobox.com
CC:
gdal-dev@lists.osgeo.org gdal-dev@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 =
RE: [gdal-dev] convert 2 shapefiles to a single GPX?
Now this I've got to try! The VRT file idea is intriguing. I didn't know it had this much flexibility... Thanks, Duarte -Mensagem original- De: Even Rouault [mailto:even.roua...@mines-paris.org] Enviada: sábado, 17 de Janeiro de 2009 20:43 Para: gdal-dev@lists.osgeo.org Cc: Duarte Carreira; Stefan Keller; Jean-Claude Repetto Assunto: Re: [gdal-dev] convert 2 shapefiles to a single GPX? Here's one solution : 1) create a directory, for example merge_shp 2) copy in merge_shp the shapefile that is going to be put in the waypoints layer as waypoints.shp (rename the .dbf and .shx accordingly) 3) copy in merge_shp the shapefile that is going to be put in the tracks layer as tracks.shp (rename the .dbf and .shx accordingly) 4) run ogr2ogr -f GPX merged.gpx merge_shp waypoints tracks (the order of the layers is important) A solution based on an OGR VRT file defining the two layers from the 2 shapefiles would also probably work. Le Thursday 15 January 2009 12:03:27 Duarte Carreira, vous avez écrit : Maybe the same approach can be used with 2 gpx files? That would be very good. I cannot merge 2 shapefiles with different geometry types. I could convert line shapegpx1 and point shape-gpx2 and then merge gpx2+gpx2-gpx3... Thanks, Duarte De: Stefan Keller [mailto:sfkel...@gmail.com] Enviada: quarta-feira, 14 de Janeiro de 2009 22:40 Para: Jean-Claude Repetto Cc: Duarte Carreira; gdal-dev@lists.osgeo.org Assunto: Re: [gdal-dev] convert 2 shapefiles to a single GPX? A merge of two shapefiles 'file1.shp' and 'file2.shp' into a new file 'file_merged.shp' is performed like this (See http://www.gdal.org/ogr/drv_shapefile.html): % ogr2ogr file_merged.shp file1.shp % ogr2ogr -update -append file_merged.shp file2.shp -nln file_merged Then convert to GPX: % ogr2ogr -f GPX out.gpx file_merged.shp Stefan http://geoconverter.hsr.chhttp://geoconverter.hsr.ch/ 2009/1/14 Jean-Claude Repetto jrepe...@free.frmailto:jrepe...@free.fr Duarte Carreira a écrit : Can OGR convert 2 shapefiles to a single GPX? The objective is to add tracks from a line shapefile and waypoints from a point shapefile... Hello, I don't know the answer to your question, but since GPX files are text files, it is very easy to merge two GPX files with a text editor. HTH ! Jean-Claude ___ gdal-dev mailing list gdal-dev@lists.osgeo.orgmailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Writing a Tiff
On Mon, 2009-01-19 at 20:57 +1100, Michael Sumner wrote: Hello, Hey Mike, thanks for your exhaustive answere :-) 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 have read that message, but my version is not affected be the one Roger refers to: ,-- library(rgdal) Loading required package: sp Geospatial Data Abstraction Library extensions to R successfully loaded Loaded GDAL runtime: GDAL 1.5.2, released 2008/05/29 GDAL_DATA: /usr/local/lib/R/site-library/rgdal/gdal Loaded PROJ.4 runtime: Rel. 4.6.0, 21 Dec 2007 PROJ_LIB: /usr/local/lib/R/site-library/rgdal/proj sessionInfo() R version 2.7.1 (2008-06-23) i486-pc-linux-gnu locale: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;\ LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;\ LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;\ LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] rgdal_0.5-33 sp_0.9-29 loaded via a namespace (and not attached): [1] grid_2.7.1 lattice_0.17-20 `-- 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)) That snipped brought my machine »to its knees« .. but that is a problem of R itself (actually, I'm currently exploring). 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 7864326 467409 3.6 tst - readGDAL(volc.tif) #volc.tif has GDAL driver ltalk X6 #and has 87 rows and 61 columns My image got dimension 8950 97907, could that dimension be the problem? Regards Henning -- . . . no signature signature.asc Description: This is a digitally signed message part ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Phase image overlay
Il giorno Mon, 19 Jan 2009 20:37:17 +0530 Chaitanya kumar CH chaitanya...@gmail.com ha scritto: Dear Antonio, I too want to know how to add transparency to a band. Please let me know when you found a way. By the way, did you try adding an alpha value to the phase file using a GDAL virtual file. Regards, OK, I suppose I could edit the color-table of the phase dataset to set an alpha value different from 255. But I can't figure out how to merge (??) magnitude and phase datasets together in a single output file (using command line GDAL tools). Thanks -- Antonio Valentino ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Update on OGR DXF Driver?
Shaun Melissa Busler wrote: I was wondering if any progress has been made on the development of an OGR DXF Driver. I saw some discussion in the archives back in 10/2008 but have not seen any postings since. Shaun, This effort appears to be stalled currently (to the best of my knowledge). Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] BandWriteArray and FlushCache question
hi list, I recently upgraded to gdal 1.6.0 and found that one Python function that used to work in 1.4.4 no longer works. The purpose of function was to read in a band, perform matrix manipulation (in this case, subtract a baseline) and resave. The error that I am getting is that in the new dataset the last hundreds of lines DN are written zero. If I take out the last line self.balanced_ds.FlushCache() then the entire dataset is written as zeros. None of errors would happen in gdal 1.4.4. Is there any changes in gdal 1.6.0 w.r.t. FlushCache() ? What is the right way to perform this? thanks, Shawn === RCS_PROC_STEP = 300 src_ds = gdal.Open(src_filename) self.balanced_ds = gdal.GetDriverByName(GTiff).CreateCopy(tmp_filename, src_ds, 0) bandobj = self.balanced_ds.GetRasterBand(1) xsize, ysize = self.balanced_ds.RasterXSize,self.balanced_ds.RasterYSize output_datatype = gdalnumeric.GDALTypeCodeToNumericTypeCode( bandobj.DataType ) nblocks = ysize / RCS_PROC_STEP + 1 nlines = RCS_PROC_STEP for block in range( nblocks ): first_line = RCS_PROC_STEP*block if block == nblocks - 1: nlines = ysize - first_line datablock = gdalnumeric.BandReadAsArray( bandobj, 0, first_line, xsize, nlines ) datablock = datablock - baseline gdalnumeric.BandWriteArray( bandobj, datablock.astype(gdalnumeric.Int16), 0, first_line ) bandobj.FlushCache() self.balanced_ds.FlushCache() ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] BandWriteArray and FlushCache question
Gong, Shawn (Contractor) wrote: hi list, I recently upgraded to gdal 1.6.0 and found that one Python function that used to work in 1.4.4 no longer works. The purpose of function was to read in a band, perform matrix manipulation (in this case, subtract a baseline) and resave. The error that I am getting is that in the new dataset the last hundreds of lines DN are written zero. If I take out the last line “self.balanced_ds.FlushCache()” then the entire dataset is written as zeros. None of errors would happen in gdal 1.4.4. Is there any changes in gdal 1.6.0 w.r.t. FlushCache() ? What is the right way to perform this? ... for block in range( nblocks ): first_line = RCS_PROC_STEP*block if block == nblocks - 1: nlines = ysize - first_line datablock = gdalnumeric.BandReadAsArray( bandobj, 0, first_line, xsize, nlines ) datablock = datablock - baseline gdalnumeric.BandWriteArray( bandobj, datablock.astype(gdalnumeric.Int16), 0, first_line ) bandobj.FlushCache() self.balanced_ds.FlushCache() Shawn, I'm not sure of any reason the script shouldn't work properly. But I will note that aspects of the TIFF file are only written out when the file is closed. You may find it helpful to do self.balanced_ds = None at the end so that python will release the dataset and it can be closed. I'm not sure of what environment you are running your script in. Normally at script end this would happen anyways. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Update on OGR DXF Driver?
we have a meeting next week (January 28) and I will discuss the issue there again. I hope that we find someone who will finance it. After all, Franks offer seems to be affordable. I will report back in a few days. Andreas Frank Warmerdam wrote: Shaun Melissa Busler wrote: I was wondering if any progress has been made on the development of an OGR DXF Driver. I saw some discussion in the archives back in 10/2008 but have not seen any postings since. Shaun, This effort appears to be stalled currently (to the best of my knowledge). Best regards, -- -- Andreas Neumann Böschacherstrasse 6 CH-8624 Grüt (Gossau ZH) Switzerland Phone: ++41-44-2736668 Email: a.neum...@carto.net Web: http://www.carto.net/neumann/ SVG Examples: http://www.carto.net/papers/svg/samples/ SVG.Open: http://www.svgopen.org/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] BandWriteArray and FlushCache question
thanks Frank. adding self.balanced_ds = None seems to do the trick. Shawn -Original Message- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam Sent: Monday, January 19, 2009 4:03 PM To: Gong, Shawn (Contractor) Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] BandWriteArray and FlushCache question Gong, Shawn (Contractor) wrote: hi list, I recently upgraded to gdal 1.6.0 and found that one Python function that used to work in 1.4.4 no longer works. The purpose of function was to read in a band, perform matrix manipulation (in this case, subtract a baseline) and resave. The error that I am getting is that in the new dataset the last hundreds of lines DN are written zero. If I take out the last line self.balanced_ds.FlushCache() then the entire dataset is written as zeros. None of errors would happen in gdal 1.4.4. Is there any changes in gdal 1.6.0 w.r.t. FlushCache() ? What is the right way to perform this? ... for block in range( nblocks ): first_line = RCS_PROC_STEP*block if block == nblocks - 1: nlines = ysize - first_line datablock = gdalnumeric.BandReadAsArray( bandobj, 0, first_line, xsize, nlines ) datablock = datablock - baseline gdalnumeric.BandWriteArray( bandobj, datablock.astype(gdalnumeric.Int16), 0, first_line ) bandobj.FlushCache() self.balanced_ds.FlushCache() Shawn, I'm not sure of any reason the script shouldn't work properly. But I will note that aspects of the TIFF file are only written out when the file is closed. You may find it helpful to do self.balanced_ds = None at the end so that python will release the dataset and it can be closed. I'm not sure of what environment you are running your script in. Normally at script end this would happen anyways. Best regards, -- ---+ -- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] 2009 Code Sprint Agenda
I've started with some higher level ideas for an agenda. Individual teams might want to start breaking out their plans into work-by-day as we get closer. http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009_Agenda P. http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
